03.03.10 | kl. 08:00 | Aktuelt, Prosabladet
Din kode kan også blive for smart
- En gang imellem er det bedre at være lidt dum og tage små skridt ad gangen i sin kode frem for at bruge en voldsomt smart feature, bare fordi den findes, siger Peter Makholm, systemudvikler hos One.com. Foto: Lars Bertelsen.
– På et tidspunkt blev jeg noget studietræt og tog springet fra den mere hardcore del af datalogien ud i den praktiske anvendelse. Først som inhouse udvikler hos Forbrugerstyrelsen i seks år og siden 2007 som systemudvikler her hos One.com, fortæller Peter Makholm, der ud over arbejdet hos One.com også lægger en del energi inden for open source-verdenen.
Peter Makholm er formelt set stadig indskrevet på Datalogi på Københavns Universitet, men tvivler på, at han vender tilbage for at færdiggøre studiet.
– Med den erfaring og det netværk, jeg efterhånden har fået gennem mit arbejde, tvivler jeg faktisk på, at det betyder det helt store, om jeg har papir på mine kompetencer, siger han.
One.com, som leverer discount webhosting, lyder måske ikke som det mest udfordrende sted at arbejde set fra et udviklerperspektiv. Men ifølge Peter Makholm ligger der i høj grad udfordringer i de store datamængder, som skal håndteres.
– Når man skal skalere et system op til 700.000 kunder, giver det nogle interessante udfordringer. Hvis man for eksempel skal læse nogle filer på disken, vil man normalt først køre et tjek for at se, om de rent faktisk er på disken. Problemet er bare, at der kan gå så lang tid, mellem at vi har tjekket den første fil, til vi skal læse den, at operativsystemet har glemt, at den eksisterer, fortæller Peter Makholm.
Så der skal jævnligt skrives noget kode til at optimere inhouse-systemerne. Og Peter Makholm skriver i Perl, der har et lidt flosset ry i udviklerkredse.
– Det er rigtigt, at der er skrevet ufattelig meget grim kode i Perl, så der er lidt sandhed i det dårlige ry. Grunden er, at Perl giver programmøren en del friheder, som han eller hun selv skal forvalte. Og så er Perl også blevet meget anvendt af systemadministratorer og webudviklere, der har haft en nu-og-her-opgave, der bare skulle løses. Og det giver jo ikke nødvendigvis den bedste kode, siger Peter Makholm og understreger, at han faktisk rigtig godt kan lide at kode i Perl.
Lær af det forkerte værktøj
Ud over at koden skal opfylde de funktionelle krav, er noget af det vigtigste for Peter Makholm, at den kan vedligeholdes. Og det betyder, at man skal passe på ikke at blive for smart.
– En gang imellem er det bedre at være lidt dum og tage små skridt ad gangen i sin kode frem for at bruge en voldsomt smart feature, bare fordi den findes. Det skal være klart, hvad der foregår i koden, og i næsten alle tilfælde er den simplere og mere overskuelige løsning den bedste, selvom den måske kræver lidt flere kodelinjer, mener han.
Han tilføjer, at hvis man benchmarker på koden, kan de flere kodelinjer i flere tilfælde faktisk også vise sig at være hurtigere end en mere komprimeret kode.
Men fascinationen af smarte features i sproget kan nemt gribe en programmør, og Peter Makholm erkender, at han også selv kan falde i.
– I Perl kan man anvende regulære udtryk, og det betyder, at nogle opgaver kan løses på to linjer komplet uforståelige regulære udtryk, og det skal man som udgangspunkt holde sig fra. Bare fordi man kan anvende en hammer til at slå en skrue i et stykke træ, så er det ikke nødvendigvis det rigtige at gøre. Modsat kan man lære meget ved at se, hvor langt man jeg gå ved at bruge det forkerte værktøj, og så blive klar over, hvornår og hvorfor det er en dårlig idé. Det vigtigste er, at man giver sig tid til at reflektere over, hvad man gør, mener han.
For Peter Makholm kan en god og måske endda smuk kode i sig selv give en stor tilfredsstillelse, men det tilfredsstillende ligger som regel på et mere praktisk plan.
– Når det lykkes for mig at skrive god kode, så gør det mit arbejde om 14 dage meget nemmere. I sidste ende handler det om at få løst opgaven – også den der kommer om 14 dage, der minder om den, jeg sidder med nu. Og min kode er god, hvis jeg kan genbruge den og nemt kan vedligeholde den, siger han.
Lur de andres kode af
I praksis er det oftest tiden, der sætter begrænsningen for, hvor god kode Peter Makholm kan skrive.
– At være programmør er under alle omstændigheder et kompromis, hvor man skal tage hensyn til mange faktorer. Det er i sidste ende et spørgsmål om 'rough consensus and running code'. Og det er en del af den faglighed, man må have, hvis man vil arbejde i en heterogen verden, mener han.
Hos One.com har man indtil videre ikke haft behov for at have nedskrevne konventioner, men det kunne ifølge Peter Makholm godt blive nødvendigt på et tidspunkt.
– Vi har indtil videre været så få udviklere og systemadministratorer, at det ikke har været nødvendigt med nedskrevne konventioner, men det begynder at knibe på nogle områder. Derudover burde man betragte dokumentation som en nødvendig del af udviklingsprocessen. Hvis vi ikke let i dokumentationen kan beskrive, hvad vi gør, så er løsningen sikkert ikke god nok. Jeg har faktisk været med til at redde projekter ved at skrive dokumentation, der har fremprovokeret den nødvendige refleksion, fortæller han.
Peter Makholm har to konkrete råd, hvis man gerne vil forbedre sin kode.
– Man skal simpelthen få læst en masse kode, som andre har skrevet, og reflektere over, hvad der er godt og skidt, og om man måske kunne bruge nogle af idéerne i sin egen kode. Det er meget mere effektivt end at sætte sig ned og læse en bog om 'god kode'.
Til gengæld er der andre bøger, det godt kan betale sig at læse.
– Jeg har en lille håndfuld bøger, som jeg synes er rigtig gode, og som jeg egentlig burde læse med faste intervaller. "The pragmatic programmer – from journeyman to master" af Andrew Hunt og David Thomas er en af dem. Den formidler med nogle konkrete eksempler, hvad der har virket godt for nogle udviklere, og lægger så egentlig bare op til, at jeg kan tænke over, om det kunne være anvendeligt for mig, fortæller Peter Makholm.
-
Dårlig kode koster
'The total cost of owning a mess'
Vedligehold og udvikling bliver rigtig dyrt i det lange løb, hvis man sjusker med koden i udviklingsfasen. Det er essensen af begrebet 'The total cost of owning a mess', som Robert C. Martin, aka 'Uncle Bob', introducerede i sin nyklassiker "Clean Code: A Handbook of Agile Software Craftsmanship" med afsæt i en let omskrivning af finanstermen 'Total cost of ownership' (TCO).
'Technical debt'
Når man første gang sender kode af sted til en kunde, er det som at stifte en gæld. En lille gældspost kan speede udviklingen op, så længe gælden bliver tilbagebetalt prompte med en omskrivning. Sådan lyder Ward Cunninghams introduktion af gældsmetaforen inden for programmering fra 1992.
Ifølge Ward Cunningham opstår faren, når gælden ikke bliver betalt tilbage. Hvert eneste minut, der bruges på en ikke helt rigtig kode, tæller som rente til gælden, og en ukonsolideret implementation af kode kan få selv de største udviklingsvirksomheder i knæ.
Links til mere information:
Ward Cunninghams introduktion af gældsmetaforen: prosa.dk/link/366.
Ward Cunningham forklarer gældsmetaforen på YouTube: prosa.dk/link/367.
Martin Fowler om, hvor stærk og nyttig, gældsmetaforen er: prosa.dk/link/368.
Robert C. Martin om forskellen mellem 'a mess' og 'technical debt': prosa.dk/link/369.
PRINT
