Jag studerade fortfarande mjukvaruteknik när jag kom i kontakt med teorin om trasiga fönster. Även om jag inte kommer ihåg när jag hörde talas om det för första gången, gjorde det ett bestående intryck på mig. Teorin kommer från ett experiment som utfördes i slutet av 60-talet, varav du hittar allt om i en bra artikel som NPR sammanställt.
Kort sagt placerade forskare två bilar, utan registreringsskyltar, i två olika områden: den första i ett utsatt område i New York och den andra i ett välbärgat område i Kalifornien. Den första bilen vandaliserades inom några minuter efter att ha övergivits, medan den andra lämnades orörd i några dagar. Forskarna bestämde sig sedan för att krossa en ruta på den andra bilen. Några minuter senare började någon stjäla delar från bilen, och den blev snabbt lika förstörd som den första.
Nyligen delade jag den här historien med en kollega under en kaffepaus. Några dagar senare berättade han att han nu tillämpar denna filosofi på sin kodning och sin kodgranskningsstil. Det var ljuv musik för mina öron, eftersom det här är något som jag alltid försöker förmedla till de team jag arbetar med.
Låt oss ta en titt på följande kod, som finns i en kodbas som jag har plockat upp och för närvarande arbetar med.
undefined
undefined
Målet är inte att undersöka orsakerna till hur och varför vi hamnade med en så komplicerad lösning, utan snarare att sätta oss i skorna på utvecklaren som ombads att ändra något i den.
Ställ dig själv följande frågor:
Ett ärligt svar pekar på nej på båda frågorna. Överkomplex kod är något som vi utvecklare är vana vid att hitta. Vi vet utantill att det tar tid att förstå och ändra koden.
Låt oss nu titta på en omarbetad version av den tidigare koden och ställa samma två frågor.
undefined
undefined
Att ändra denna kod är överlägset lättare än att ändra den föregående. Och i motsats till vad som vanligtvis går igenom en utvecklares sinne när tidsfristerna är snäva, hjälper det att hålla kodbasen liten och välorganiserad.
Vi tänker ofta inte på hur det att hålla koden i gott skick sätter ribban för andra som arbetar med projektet. Men ett projekt med välskriven kod kommer att motivera alla att efterlikna beteendet, följa konventionerna och leverera kod med liknande kvalitet. Om det inte finns några trasiga fönster i projektet kommer människor att bli mindre frestade att krossa ett.
Det som är bra med att vårda ett beteende utan trasiga fönster är att det i slutändan kommer att spridas genom hela mjukvaruutvecklingsteametoch påverka alla projekt i företaget. Förhoppningsvis kommer detta också att fungera som en signal till andra avdelningar, så att filosofin antas utanför företagets kodbas.
Tanken på trasiga fönster dyker upp då och då, eftersom det är ett utmärkt exempel på hur små beteenden är avgörande för att undvika att problem eskalerar och att system i slutändan förfaller i kaos. Det är en av de principer som är värda att leva efter.
Tyckte du att den här artikeln var intressant? Då kanske du även gillar dessa!
VD på Imaginary Cloud och medförfattare till boken Product Design Process. Jag gillar mat, vin och Krav Maga (inte nödvändigtvis i den ordningen).
LinkedIn
People who read this post, also found these interesting:
