03.03.10 | kl. 08:15 | Aktuelt, Prosabladet
Kode er også kommunikation
- Som programmør skriver jeg koden én gang, men der kommer rigtig mange mennesker efter mig, der skal kunne forstå min kode for at rette i den eller videreudvikle på den, siger Christian Horsdal, softwareudvikler og -arkitekt hos Mjølner Informatics. Foto: Søren Holm/Chili.
Christian Horsdal er datalog og ansat i det århusianske udviklingshus Mjølner Informatics som softwareudvikler og -arkitekt. Som formand for husets procesfællesskab af softwarearkitekter er han også med til at definere god kodeskik.
– Det er vigtigt at holde fast i, at som programmør skriver jeg koden én gang, men der kommer rigtig mange mennesker efter mig, der skal kunne forstå min kode for at rette i den eller videreudvikle på den. Og jeg skal også selv hurtigt kunne sætte mig ind i den igen, hvis jeg skal tilbage til den om nogle måneder.
Så på den måde skal man også tænke på kode som kommunikation med en afsender og en målgruppe, hvor afsenderen skal forsøge at sætte sig i læsernes sted og udforme sin tekst, så den bliver læsbar for andre, mener han.
Set over en længere periode kan det ifølge Christian Horsdal helt sikkert betale sig at skrive god kode fra starten. Robert C. Martins og andres pointer om 'total cost of owning a mess' og 'technical debt', hvor renterne over tid bliver utroligt høje, er han helt enig i.
Navngiv metoder meningsfuldt
Hos Mjølner har man ud over de rent funktionelle krav til koden formuleret fire grundlæggende ikke-funktionelle kvalitetskrav: Performance, security, reliability og maintainability. Mange af Mjølners løsninger bliver faktisk overdraget til andre teknologivirksomheder, der får ejerskab over kildekoden, så kravet til maintainability er ekstra stort her. Maintainability, altså graden af vedligeholdelsesbarhed, er overskriften for læsbarhed, som Christian Horsdal mener kan opnås på flere måder.
– Man ser tit, at tomme linjer i koden bliver forsøgt brugt til at gruppere nogle elementer i koden, der hører logisk sammen. Her foretrækker jeg at tage de elementer og trække dem ud i en anden metode, som jeg så kalder. Jeg kan også godt lide gode beskrivende navne på metoder. Det kan typisk hjælpe programmører uden så meget domænekendskab til at forstå, hvorfor man for eksempel udfører nogle bestemte beregninger eller tjek, siger han.
Christian Horsdal mener, at det ikke skader læsbarheden, at metoder kalder andre metoder. Det er samtidigt også vigtigt at huske på Martin Fowlers råd om at lade metoderne bevæge sig på samme abstraktionsniveau.
Christian Horsdal arbejder til daglig mest med .NET. Han mener, at kodning kan gå godt eller skidt i alle sprog, men der er dog sprog, hvor det er sværere at gøre koden læsbar.
– Perl kan være rigtig svært at gøre læsbar. I den anden ende af spektret ligger Ruby, og så har vi C# og Java et sted i midten, mener han.
Og så er der spørgsmålet om kodekommentarer, som han ikke giver så meget for.
– Personligt stoler jeg ikke rigtig på kommentarerne, da de ofte ikke er opdaterede, mens selve koden pr. definition er up to date. I de forholdsvis sjældne tilfælde, hvor man kommer ind i noget algoritmisk, kan det være nyttigt at henvise til den matematik, der er på spil. Og noget mere domænespecifikt eller udefrakommende kan det også give mening at forklare i en kommentar, hvis der for eksempel af lovgivningsmæssige årsager skal udføres ting som audit trail i koden, siger han.
Der er mange hensyn at tage, når der skal skrives kode. Og for Christian Horsdal bliver man nødt til at forholde sig professionelt til det nødvendige kompromis mellem tiden, man har til rådighed, og den optimale kode.
– Det kan godt initielt tage lidt længere tid at skrive god kode. Så i visse tilfælde kan man blive tvunget til at lave en quick-and-dirty. Men det er så lidt, man sparer af tid, så hvis deadlinen bare ligger nogle dage fremme, så vil jeg skrive koden ud fra mine krav til eksempelvis læsbarheden, fortæller han.
Værdien af god kode
På det mere praktiske plan sværger Christian Horsdal til mange små iterationer, når han koder. Ikke blot de iterationer, der ligger i procesmodeller som Scrum, men de små iterationer i løbet af en dag, hvor han tilstræber hele tiden at få tjekket sin kode af og ind i versionsstyringsværktøjet.
– Groft sagt bør man skrive fem linjer, køre dem, så skrive fem linjer mere og køre dem. Det tvinger en til at skrive korte metoder og korte klasser, hvilket igen fremmer læsbarheden, siger han.
Men det er ikke nok, at den enkelte udvikler har fokus på kvalitet i koden.
– Der skal være en kulturel forståelse i virksomheden for værdien af god kode. I princippet kunne man godt sige, at det er o.k. at lave mindre god kode, hvis man gør det med åbne øje, og fordi det giver mening nu og her. Det er bare ikke mit indtryk, at det er det, der har været baggrunden, når jeg ser dårlig kode. Der er steder, hvor kvalitet i koden simpelthen ikke er i fokus, mener Christian Horsdal.
Hvis ikke der er tungtvejende grunde til at lade være, anvender man hos Mjølner eksempelvis Suns og Microsofts officielle kodestandarder. I nogle tilfælde justerer man dog standarderne i de enkelte projekter, da kunderne kan have specifikke krav.
Christian Horsdal synes, at han fik en god ballast med fra sin uddannelse på Datalogi på Aarhus Universitet.
– Man lærer først rigtigt at blive programmør, når man kommer ud i en udviklingsvirksomhed. Men jeg fik nogle gode konkrete ting med mig som for eksempel viden om compilere og virtuelle maskiner. Og selvom der selvfølgelig er meget håndværk i at skrive god kode, så er der nogle teoretiske forudsætninger, der skal være på plads, før man kan udføre sit håndværk i den nødvendige kvalitet, mener han.
PRINT
