Har du noen gang gått gjennom en skog og plutselig støtt på en slags elefantkirkegård for hvitevarer? Et sted dit vaskemaskiner vandrer med melankolske skritt når de merker at sentrifugalkraften har avtatt, ser seg rundt og så skrur seg av for siste gang mens vinden virvler lukt av vaskepulver og tøymykner inn i evigheten?
Hvordan kan det være at alt dette skrammelet ender opp akkurat her?
Og hva har en teori oppkalt etter et knust vindu med dette å gjøre?
Kan det være så nøye?
Jeg satt og så på en pull request fra en juniorutvikler. Han hadde kalt en komponent som skulle vise innholdet i en tabellcelle for ClientInfoTD.
Ikke noe problem med det, bortsett fra at alle andre komponenter som viste celler i denne kodebasen slutta med Td - altså med den andre bokstaven liten.
- Seniorutviklere glemmer at de har vært juniorer
Jeg scrolla oppover og så på de andre tilbakemeldingene jeg hadde gitt denne relativt ferske utvikleren, og lærerhjertet mitt bønnfalt meg om at nå fikk det være nok.
Kan det virkelig være så nøye om én bokstav er skrevet smått eller stort?
Et knust vindu
I 1969 gjennomførte forskeren Philip Zimbardo et forsøk.
Han satte ut en bil i et rikt nabolag i California og lot den stå der. De første ukene fikk den stå i fred. Da gikk Zimbardo bort og knuste ett av vinduene med en hammer. Etter det gikk det bare 24 timer så var bilen totalt ødelagt og alt av verdi var fjerna.
Der jeg vokste opp, lå det ofte en ball uten luft på en lekeplass eller en fotballbane. Når en gjenstand er skadd uten at skaden blir fiksa innen rimelig tid, kringkaster det en melding om at eieren, om hun i det hele tatt finnes, ikke bryr seg.
Som denne ballen eller bilen med flate dekk som har stått borti gata i månedsvis, det området av skogen der alle setter de ødelagte hvitevarene sine - eller den koden der alle har fått lov til å skrive navn på variabler og funksjoner akkurat som de vil.
Knut forsker på typesystemer - for ja, det kan man
Teorien som den før omtalte Zimbardo undersøkte, er blitt kjent som “teorien om knuste vinduer” eller “the broken window theory.”
Den førte blant annet til at politiet begynte å slå hardere ned på tilsynelatende små ting tidlig, fordi de skjønte at det er mye lettere å stoppe noe mens det enda er i sin spede begynnelse. Det er vanskeligere å tagge på en helt ren vegg enn på en der det allerede står noe obskønt - så hold den ren. Det er mye lettere å dra med seg det ødelagte kjøleskapet ut i skogen dersom det allerede står en komfyr der som kan holde det med selskap - så rydd vekk den første komfyren så fort som mulig.
«Den var blitt en vegg dekka av tagging med knust glass utover gulvet og en ubestemmelig stank av spagettikode.»
Som Zimbardo sier: “There is considerable reluctance to take that first blow, to smash through the windshields and initiate the destruction of a form”. “The seconds blow”, derimot, er plutselig en god del enklere.
Kodebase med knuste vinduer
På hvilken måte er dette så relevant for oss som jobber med utvikling?
Jeg overtok en gang en kodebase der nesten alt av businesslogikk lå i globale funksjoner i èn gigantisk fil på over 5.000 linjer. Jeg oppdaga videre at kode som skulle takle båter, var kopiert fra kode som takla biler, men variabelnavnet var ikke endra fra car til boat.
Dette NAV-systemet har vært i drift siden 1978
Jeg kjenner ikke til historikken til denne koden, men jeg har vanskelig for å tro at det begynte der, selv om det absolutt er en mulighet det også. Det begynte nok med noe smått - som navngivingskonvensjon. Så fort utviklerne skjønte at her var det fritt fram, var ikke veien lang til å velge minste motstands vei også i andre spørsmål.
Det er klart det er fristende å legge en funksjon i en fil som allerede har altfor mange fra før - den må jo ryddes opp i uansett - i stedet for å finne et mer passende sted.
Etter at denne onde spiralen hadde pågått en stund, var det færre og færre som brydde seg om koden. Den var blitt en vegg dekka av tagging med knust glass utover gulvet og en ubestemmelig stank av spagettikode. En vegg det er vanskelig å føle stolthet over, og lite lystbetont å ta eierskap til.
Da er løpet kjørt. Ingen bryr seg mer, og man får bare mer og mer lyst til å kaste den og skrive alt på nytt...
Sinnautvikleren
Motvillig knipsa jeg vekk den lille læreren som hadde satt seg på den ene skuldra mi og gav high-five til sinnautvikleren på den andre skuldra.
Deretter skreiv jeg en tilbakemelding om at det var viktig å bruke samme navngivingskonvensjon overalt i koden. En slik liten forskjell kan faktisk være det første hakket i kodebasens vindu.
Fra junior til senior - så mye har titler å si for utvikleres lønn
Så hva kan vi gjøre for å unngå å få knuste vinduer i koden vår? Jeg tror det er to svar:
- Vi må være kompromissløse når det gjelder kodekvalitet i både store og små ting. Her har seniorutvikleren, som vet og har erfart både hvordan god og dårlig kode ser ut, et spesielt ansvar overfor juniorene som uunngåelig vil gjøre feil uten å være klar over det. Ikke ta lett på code reviews!
- Videre må vi ikke tillate at dårlige valg, store eller små, får fotfeste i koden vår. Å gjøre feil er lov, men når vi oppdager at noe er feil eller dårlig, bør det settes av tid til å gjøre noe med det så fort som mulig før teamet venner seg til at det er sånn koden er. Som frosken som sakte, men sikkert blir kokt uten å merke det, vil synet vårt på koden endre seg fra “denne koden er bra”, til “denne koden er bra - bortsett fra X” til “det er en del feil i denne koden, og den ser ikke ut til å være viktig nok til at det foreligger planer om å gjøre noe med dem”. Før vi vet ordet av det, er koden blitt til den fryktede klassikeren: “stakkars den som må overta denne koden etter oss”.
Den personen som overtar koden kan fort ende opp med å være noen du er glad i. Så ikke la knuste vinduer få danse på kodebasen fordi utvikleren ikke passer på!
