Jeg studerede stadig software engineering, da jeg kom i kontakt med Teori om ødelagte vinduer. Selvom jeg ikke kan huske, hvornår jeg hørte om det for første gang, gjorde det et varigt indtryk på mig. Teorien kommer fra et eksperiment, der blev udført i slutningen af 60'erne, hvoraf du finder alt om i en god artikel som NPR har sat sammen.
Kort sagt placerede forskere to biler, fjernet fra deres nummerplader, i to forskellige områder: den første i et problematisk kvarter i New York og den anden i et rigt kvarter i staten Californien. Den første bil blev vandaliseret inden for få minutter efter at være blevet forladt, mens den anden blev efterladt alene i et par dage. Forskerne besluttede derefter at bryde et vindue i den anden bil. Et par minutter senere begyndte nogen at stjæle bilens dele, og den blev hurtigt lige så ødelagt som den første.
For nylig delte jeg denne historie med en af mine kolleger i en kaffepause. Et par dage senere fortalte han mig, at han nu anvender denne filosofi på sin kodning og kodegennemgangsstil. Dette var musik i mine ører, da det er noget, som jeg altid prøver at videregive til de hold, som jeg arbejder med.
Lad os se på følgende stykke kode, fundet i en kodebase, som jeg har hentet og i øjeblikket arbejder med.
Målet er ikke at undersøge årsagerne til, hvordan og hvorfor vi endte med en så overkompliceret løsning, men snarere at sætte os i skoene til udvikleren, der blev bedt om at ændre noget i det.
Stil dig selv følgende spørgsmål:
Et ærligt svar vil pege på ingen på begge spørgsmål. Overkompleks kode er noget, som vi, udviklere, er vant til at finde. Vi ved udenad, at det tager tid at forstå og ændre koden.
Lad os nu se på en refaktoriseret version af den forrige kode og stille de samme to spørgsmål.
At ændre dette stykke kode er langt lettere end at ændre det forrige. Og i modsætning til hvad der normalt løber gennem en udviklers sind, når deadlines er stramme, hjælper det at holde kodebasen lille og velorganiseret.
Vi tænker ofte ikke på, hvordan det at holde koden i god form sætter baren for andre, der arbejder på projektet. Men et projekt med en velskrevet kode vil motivere alle til at efterligne adfærden, følge konventionerne og levere kode med lignende kvalitet. Hvis der ikke er ødelagte vinduer på projektet, vil folk blive mindre fristet til at bryde en.
Den gode ting ved at pleje en ubrudt vinduesadfærd er, at den i sidste ende vil formere sig gennem det hele softwareudviklingsteam, og påvirke alle projekter i virksomheden. Forhåbentlig vil dette også fungere som et tegn til andre afdelinger, og filosofien bliver vedtaget uden for virksomhedens kodebase.
Oplevelsen af brudt vindue kommer op i mit sind nu og da, da det eksemplificerer den betydning, som mindre adfærd har for at undgå problemer med skalering og i sidste ende systemer fra at falde i kaos. Det er en af de regler, som det er værd at leve efter.
Fandt du denne artikel interessant? Du kan måske også lide disse!
CEO @ Imaginary Cloud og medforfatter af bogen Product Design Process. Jeg nyder mad, vin og Krav Maga (ikke nødvendigvis i denne rækkefølge).
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
