Småt er godt - så hvorfor skriver vi klasser på 20.000 linjer?
Hvad er den ideelle størrelse på et program, målt i kodelinjer? Svaret er kompliceret, men der er fornuft i at søge mod småt snarere end stort, for selvom organisationer er vilde med at søsætte store it-projekter, så er de små ofte bedre.
Hovedproblemet med kodemængder over en vis størrelse er, at det bliver umuligt for den enkelte udvikler at holde styr på, hvad koden indeholder.
»For al software må der findes en 'passende størrelse'. Det er så et optimeringsproblem at prøve at finde den størrelse. Men udgangspunktet må være noget, der har en størrelse, så du kan rumme den i dit hoved og arbejde med den,« sagde softwarekonsulent Kevlin Henney i et oplæg på udviklerkonferencen Goto 2016 i København.
Tidlige it-systemer havde fysiske begrænsninger som eksempelvis mængden af hukommelse. De spiller en mindre rolle i dag - i hvert fald når det gælder størrelsen på den kode, udviklerne arbejder med.
Selv noget så omfattende som styresystemet Unix var i 1970'erne på nogle få tusinde linjer. Sjette udgave af Unix var på cirka 10.000 linjer, og det gjorde koden til nærmest en lærebog i sig i, hvordan et styresystem fungerer.
»I dag har jeg set Java-klasser på 20.000 linjer,« sagde Kevlin Henney.
Hvis koden passerer det punkt, hvor udvikleren har et instinktivt overblik over, hvad den indeholder, og hvad der gør hvad, så har man introduceret risikoen for at ende med et system, der er stort og svært at vedligeholde.
Homøopatisk navngivning
Kodevokseværk er ikke kun et problem med systemarkitekturen. Det begynder ofte i det små, hvor eksempelvis lange kodelinjer bliver en kilde til fejl, fordi de passerer en grænse for, hvad der er nemt at læse for et menneske.
»Selvom vores skærmteknologier har udviklet sig, så er vores visuelle kapacitet ikke fulgt med. Så 80 kolonner til tekst kan føles som en meget 70'er-agtig begrænsning, men faktisk har mennesker svært ved mere end 50-60 kolonner,« sagde Kevlin Henney.
I et konkret projekt fandt de frem til, at de ved at se på de linjer, der strakte sig langt ud over de øvrige, fandt en del fejl. En enkelt linje strakte sig mere end 300 kolonner.
Læsevenlig kode er et omdiskuteret emne i programmering, fordi ikke alle er enige om, hvad det egentligt dækker over. Meget kompakt kode med den syntaks, der bruger færrest tegn, er ikke altid lige let at læse for enhver anden udvikler, der skal gennemskue, hvad koden faktisk gør.
Omvendt kan overflødige deklarationer også gøre det sværere at holde styr på, hvad der foregår.
Et eksempel kan være navngivning af metoder og variable, hvor der kan gå inflation i det, når navnene skal afspejle programmets struktur.
»Det bliver til homøopatisk navngivning,« sagde Kevlin Henney med henvisning til, at længden til sidst fortynder betydningen så meget, at den forsvinder.
Et langt større problem er imidlertid kode, der sniger sig med ind i projekter, selvom den var tiltænkt bare at blive brugt midlertidigt. Og vi er mere tilbøjelige til at holde fast i kode, vi har skrevet, jo større den er.
Det er der ingen grund til, for i modsætning til at bygge et højhus, så er omkostningerne ved at gå lidt tilbage og prøve en ny tilgang, forholdsvis små, når man skriver software. Og med versionsstyring har udvikleren nærmest en tidsmaskine ved hånden.
Software er billigst i små pakker
Prisen på software er selv i bedste fald ikke lineær proportional med antallet af kodelinjer. Tværtimod begynder prisen at stige pr. linje, når man når over en hvis størrelse, som kræver flere test og flere hensyn, der skal tages.
Det er ikke åbenlyst for dem, der køber et system, at de får mere for pengene ved at købe små systemer. Lad os eksempelvis sige, at en offentlig myndighed skulle bruge et it-system, så vil de ofte bestille ét system, der kan understøtte et komplet område - for eksempel gældsinddrivelse.
Men der er ikke noget, der hedder mængderabat i softwareudvikling.
»Mælk er billigst, hvis du køber en stor karton i stedet for flere små kartoner. Men software er billigst i små kartoner,« sagde Kevlin Henney.
Problemet er ofte, at kunden bestiller software, der afspejler den måde, organisationen opfatter sig selv på. Men når det skal implementeres, så kommer systemet til at afspejle den måde, organisationen i virkeligheden fungerer på, og det er ofte mere kompliceret end blot eksempelvis et hierarki med adskilte afdelinger.
Derfor bør man være klar over, at virkeligheden formentligt er mere rodet, end man tror, og at det vil afspejles i det store it-system.
En af fordelene ved at skrive flere små it-systemer til afgrænsede opgaver i stedet for det store forkromede system er, at det kan klares inden for en overskuelig tidshorisont af et lille hold udviklere.
Det er nemlig et klassisk problem inden for softwareudvikling, at flere udviklere på en opgave ikke giver en tilsvarende fremdrift i projektet, hvis man har passeret et vist mætningspunkt.
Populært sagt kan man sætte så mange folk på at løse et lille problem, at det ender med at blive et stort problem, fordi flere mennesker indebærer mere interaktion og kommunikation, så der bruges forholdsvis flere ressourcer på overhead i projektorganisationen.
»Når du over en vis størrelse, så tilføjer du folk for at kompensere for, hvor mange folk, du har på opgaven,« sagde Kevlin Henney.
Han advokerer for, at man i sine projekter tænker i 'bæredygtig softwareudvikling'. Det vil sige kode, der opfylder nutidens behov, men uden at det begrænser fremtidige generationers muligheder for tilsvarende at opfylde deres behov - en definition lånt fra bæredygtighed i miljøsammenhæng.
Et af rådene er dog lidt i modstrid til, hvad man taler om i forhold til miljø og ressourceforbrug:
»Vi skal blive bedre til at tale om, hvordan vi smider kode væk,« sagde Kevlin Henney.
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
