For et stykke tid siden snakkede jeg med en kollega, hvis arbejde ligesom mit er baseret på teori og beregninger. Han fortalte, at han ofte, når han er midt i processen med at skrive kode til at simulere de systemer, han arbejder med, forfalder til ad-hoc løsninger i koden, efterhånden som problemstillingen udvikler sig.
En hurtig if-sætning her, en hurtig for-løkke der. Løsninger, som lige nu gør det ønskede, og som derved leder til de data og resultater, han er ude efter. Men som rent kodemæssigt ikke er hensigtsmæssigt. Alt dette i håbet om, at han aldrig skal bruge koden igen, når resultaterne er opnået, data behandlet og analyseret, og arbejdet udgivet. Kort og godt: Hurtig akademikerkode.
("Piled Higher and Deeper" by Jorge Cham, www.phdcomics.com)
Jeg kender godt selv følelsen, at det bare er nemmere - lige nu - med en hurtig løsning. Men man opbygger på denne måde "gæld" i sin kode, og på sigt bliver den typisk sværere at udvide og ændre - og at læse og forstå, når man senere kigger på detaljerne.
Nogle få ildsjæle skriver og udgiver open source kodepakker til gavn for andre forskere, men i de fleste tilfælde - i hvert fald i det akademiske - skriver man koden til sig selv og ingen andre. Dette kan til dels forklare hurtige løsninger, men koden bliver således nemt en smule indforstået. Selvom jeg altid forsøger at skrive grundige kommentarer overalt i min kode, falder jeg jævnligt over steder, som hverken er kodet eller kommenteret optimalt.
I mit ph.d. projekt udvikler arbejdet sig i sagens natur løbende, og jeg har ugentligt behov for at ændre større eller mindre dele af den Matlab kodepakke, jeg udvikler og laver analyser med. Det er grundlæggende ingen undskyldning, men i processen, hvor vi tester forskellige idéer, strukturer og teorier - hvilket alt sammen foregår ved at ændre forskellige dele af koden - forfalder jeg ofte til at lave ændringerne hurtigt og specielt uden at kommentere dette grundigt. Mentalt noterer jeg mig dette, og med jævne mellemrum dedikerer jeg tid til at rydde koden op - til at tilbagebetale "gælden".
Som med debugging handler det om at tage sig tid til at skrive ordentlig og robust kode. Men når man som mig ikke er softwareingeniør, men fysiker er det mest interessante ikke selve koden, men de resultater og analyser, den kan producere. Og så er det bare sjovere at få resultaterne lige nu!
Retfærdigvis skal det siges, at jeg - og forhåbentlig mange andre - investerer en del tid i at gennemtænke den kode, vi udvikler. I slutningen af sidste år opstod der et væsentligt problem i mine beregninger, og jeg brugte i den forbindelse en del tid på at forbedre og optimere min kode. Jeg skal snart i gang med at udvikle ny kode til endnu mere krævende beregninger af tredimensionelle strukturer, og her skal der træffes mange "gode kodebeslutninger".
Koden skal dog langt hen ad vejen kun betjenes af mig selv - så jeg håber ikke, at jeg forfalder til hurtig akademikerkode.
