Efekt teorii rozbitych okien, czyli wandalizm w inżynierii oprogramowania

Podczas pracy z dziesiątkami systemów informatycznych, setki razy słyszałem teksty, które za każdym razem budzą mój nieustający zachwyt:

nie da się zrobić tego lepiej, bo trzeba byłoby dużo przerabiać...

albo:

po prostu, to jest tak tu robione, więc też tak robię...

lub legendarne już:

nie siedzę tutaj, żeby grzebać w tym bagnie... piszę swoje i fajrant!

Tego typu reakcje są objawem zderzenia się z brutalną rzeczywistością dotyczącą jakości kodu, z którym przychodzi nam pracować. Często jest to szokujące dla młodych programistów, z czasem staje się normalnym stanem rzeczy.

Co wspólnego ma teoria rozbitych okien z programowaniem?

Teoria rozbitych okien opisuje efekt socjologiczny, który polega na naśladownictwie patologicznego zachowania. Z wyjaśnieniem terminu jak zawsze przychodzi Wikipedia. Zbierając doświadczenia z bardzo wielu systemów mogę śmiało stwierdzić, że dokładnie to samo dzieje się w IT. Inaczej mówiąc, sama obecność niskiej jakości kodu powoduje, że programiści pracujący na nim znacznie częściej wyprodukują równie słaby kod bez wyrzutów sumienia.

Wniosek z tego jest prosty, ten cykl jest samonapędzający. Każdy kompromis w jakości odbije się czkawką w przyszłości. Jest to jedna z najważniejszych rzeczy, którą trzeba wziąć pod uwagę, kiedy przymykamy oko i akceptujemy kompromisy w jakości kodu.

Związek efektu rozbitych okien z KISS i Convention Over Configuration

Czy temat jest wyczerpany? Czy zawsze musimy zaorać brzydki kod z obawy przed padnięciem systemu w przyszłości?
No właśnie okazuje się, że nie.
Spostrzegawczy czytający może od razu mi wytknąć:

A czy nie słyszał Pan Marcin o konwencjach? Konwencja w systemie, nawet jeśli jest nieoptymalna powinna być zachowana.

Cóż mogę odpowiedzieć – całkowita racja! Mogę stwierdzić nawet mocniej – nie ma nic gorszego jak niekonsekwencja i utrzymywanie wielu standardów implementacji w systemie na raz. Bardzo często stajemy przed dylematem użycia przestarzałych konwencji, które są naleciałością z przeszłości. W takim wypadku zmiana starego rozwiązania w części lub całości kodu może nie być najlepszym rozwiązaniem. Wkraczamy tutaj w zagadnienia KISS i Convention Over Configuration, które omówię dokładnie w odpowiednich postach.

W takim razie, czy zawsze powinniśmy modernizować nieoptymalne rozwiązania?

Jednoznaczna odpowiedź na ten dylemat jest moim zdaniem niemożliwa. Wszystko zależy od przypadku i jest to idealny przykład sztuki architektury oprogramowania. Na jednej stronie szali mamy chęć pozbycia się starych i brzydki rozwiązań, z drugiej strony takie zmiany mogą zaburzyć dobrze działające schematy i konwencje. Każda taka decyzja to delikatny balans wielu racji i argumentów. Niestety, bez dużej ilości doświadczeń z takimi dylematami, dobra decyzja jest bardzo trudna.

Leave A Comment