Jag studerade fortfarande mjukvaruteknik när jag kom i kontakt med Teori 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, avskalade från sina registreringsskyltar, i två olika områden: den första i ett problematiskt område i New York och den andra i ett rikt område i delstaten Kalifornien. Den första bilen vandaliserades inom några minuter efter att ha övergivits, medan den andra lämnades ensam i några dagar. Forskarna bestämde sig sedan för att bryta ett fönster i den andra bilen. Några minuter senare började någon stjäla bilens delar, och den blev snabbt lika förstörd som den första.
Nyligen delade jag den här historien med en kollega till mig under en kaffepaus. Några dagar senare berättade han för mig att han nu tillämpar denna filosofi på sin kodning och kodgranskningsstil. Det här var musik för mina öron, eftersom det här är något som jag alltid försöker förmedla till de lag som 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.
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.
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 en 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 på projektet kommer människor att bli mindre frestade att bryta en.
Det som är bra med att vårda ett obruten fönsterbeteende är att det i slutändan kommer att spridas genom hela mjukvaruutvecklingsteamoch påverka alla projekt i företaget. Förhoppningsvis kommer detta också att fungera som ett tecken för andra avdelningar, och filosofin antas utanför företagets kodbas.
Upplevelsen av trasiga fönster kommer till mitt sinne då och då, eftersom det exemplifierar vikten som mindre beteenden har för att undvika problem från skalning och i slutändan system från att falla i kaos. Det är en av reglerna som det är värt att leva efter.
Tyckte den här artikeln intressant? Du kanske gillar dessa också!
VD @ Imaginary Cloud och medförfattare till boken Product Design Process. Jag gillar mat, vin och Krav Maga (inte nödvändigtvis i denna ordning).
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
