Hvordan døber man variable, metodenavne, klasser og alt det andet, en kodebase består af, så koden kan læses og forstås af udviklere i mange år fremover?
Sådan lyder et af de store spørgsmål, som udviklerne hos det danske softwarefirma e-conomic har sat sig for at give et godt svar på.
Den københavnske virksomhed, som Version2 besøger tirsdag på sommertouren, fremstiller webbaserede regnskabsprogrammer.
Løsninger af den slags, man i dag vil putte ind i kategorien cloud computing. Men firmaet er stiftet i 2001, og dermed rækker både historien og kodebasen hos e-conomic noget længere tilbage end modeordets fødsel.
»Vi er et gammelt hus i den forstand, at vi har været med i lang tid før, det overhovedet hed cloud computing. Vi har oplevet, at organisk vækst i en kodebase betyder afvigelser, og flere og flere udviklere betyder flere og flere afvigelser. På et tidspunkt når man en kritisk masse af udviklere, som ikke har været med fra starten og derfor ikke kender konteksten for al koden,« fortæller seniorudvikler Rasmus Beck, e-conomic, til Version2.
Hans egen karriere i virksomheden begyndte i oktober 2012, og han kunne rimeligt hurtigt se, at virksomheden blev nødt til at finde et fælles fodslag for navngivning af kildekoden.
»Hvis koden ikke er navngivet meget, meget præcist, så er det nødvendigt at tage fat i de udviklere, der er gamle i gårde, for at få forklaret konteksten. Det ville jeg gerne ud over,« siger Rasmus Beck til Version2.
Et helt friskt eksempel fra udviklingsafdelingen er variabelnavnet location, som for et par uger siden førte misforståelser med sig.
For e-conomics egne udviklere var ordet 'lokation' rigeligt specifikt og dækkende. Men bogføring er et domæne præget af en bestemt terminologi, så sådan var det ikke nødvendigvis for andre:
»I vores interne DSL (domænespecifikke sprog, red.) ved folk godt, hvad man taler om, når man siger lokationer. Men jeg talte så med en anden person udefra, som kunne forstå ordet på en anden måde. Og derfor er det enormt vigtigt, at man ud fra navngivningen af bare den ene variable kan sætte en kontekst, som er beskrivende,« siger Rasmus Beck.
I det konkrete eksempel blev navnet location konkretiseret til inventoryLocation for at angive, at der er tale om et nærlager.
Hos e-conomic benytter man Pascal Casing til klasse- og metodenavne og Camel Casing til variable. Det gælder både for C#- og JavaScript-koden, men det har mere at gøre med stil end med selve forståelse af koden.
public class Customer
{
...
public Customer CreateIfNotExists()
{
if (null == id || !Exists(id))
return Create();
return FetchCustomer();
}
}Eksempel på den nye måde at navngive kode hos e-conomic. Metoden CreateIfNotExists hed tidligere bare Create.
For Rasmus Beck er det nu blevet lidt af en personlig mission at indføre en kultur blandt udviklerne, som gør, at koden forklarer sig selv uden at skulle have en uddybende tekst som krykke.
Det kan være fint at skrive fem linjer med forklarende tekst til hver metode, hvis man vedligeholder et offentligt API.
Men for en intern udviklingsafdeling er det bare symptombehandling, mener Rasmus Beck.
Seniorudvikleren har fået hjælp til opgaven af husets egen tekstforfatter, der er ansat specifikt til at skrive dokumentation til koden.
»Det er en disciplin, som er væsentlig sværere at indføre end som så. Det kræver en enighed på tværs af alle udviklere og udviklingsafdelinger, og det kræver en form for domænespecifikt sprog, som man også kan blive enige om,« siger Rasmus Beck.
»Når først man tør bruge tekstforfatteren, får man rigtig mange positive ting ud af det. Det er ud fra en erkendelse af, at udviklere er gode til at skrive kode og ikke altid til at kommunikere,« forklarer Rasmus Beck til Version2.
En vigtig afledt effekt af den nye fremgangsmåde er i sidste ende en mere robust kode, forklarer Rasmus Beck.
»Hvis man har svært ved at navngive præcist, hvad koden dækker over, så sker der for mange ting samme sted, og så bør man refaktorere, så koden bliver mere simpel og lettere forståelig - og dermed også lettere at navngive,« siger han.
På værktøjssiden bruger e-conomic Facebook's Phabricator til code review og repository browsing. Det hjælper med til at understøtte den nye måde at navngive på, hvor udviklerne er så konkrete og entydige som muligt.
Men det har også krævet en ny kultur med en særlig boyscout rule, forklarer Rasmus Beck.
Den indebærer, at alle udviklere, der er inde at røre ved den gamle del af kodebasen, sørger for at opdatere den en smule i overensstemmelse med de nye regler.
»Der vil selvfølgelig opstå navngivning, som er i konflikt med den gamle måde at gøre det. Men vores boyscout rule siger, at du skal efterlade koden pænere end den, du kom til,« siger Rasmus Beck.
Svært at måle
Rasmus Beck oplever nu, at udviklerne i hans eget team har større fokus på navngivningen af koden.
Forskellen fra før til nu er i sagens natur svær at måle. Men konkret kan det ses ved, at de udviklere, der har været med fra begyndelsen, nu får færre spørgsmål til legacy-koden.
»Men det er svært at måle på, så det er mere en blød metrik,« konstaterer han.
Det lyder jo meget godt, men hvis du nu pludselig får nyt job, er det så blevet en fast nok del af kulturen hos udviklerne til at blive videreført?
»Ja, det synes jeg. Jeg har en forståelse af, at folk synes, det er en god idé. Jeg ved, at der er andre udviklere, som har kæmpet den her kamp, før jeg kom til, så jeg er ikke den eneste,« siger Rasmus Beck.
Denne artikel er en del af Version2's sommertour, hvor vi flytter redaktionen ud til en stribe danske it-firmaer. Se hele tour-kalenderen
