Teoria rozbitych okien w… tworzeniu oprogramowania

Tytułowa teoria wywodzi się z dziedzin kryminologii i socjologii miasta. Nigdy nie słyszałem o tej drugiej ale jestem w stanie uwierzyć na słowo. Posiłkując się encyklopedią czytamy, że zgodnie z tą koncepcją brak reakcji na łamanie ogólnych norm społecznych w danym obszarze zadziwiająco często sprzyja wzrostowi przestępczości i dalszemu łamaniu owych norm na tym samym obszarze.

Mówiąc jednak po ludzku, chodzi o to, że tak długo jak dana okolica jest czysta, mury nie są pomazane farbą, a szyby w oknach są całe, lokalna społeczność nie będzie skłonna zmieniać tego stanu rzeczy. Jednak w momencie gdy w okolicy da się dostrzec brudne ściany, śmieci na ulicy czy powybijane szyby w zamkniętej dawno fabryce, z jakiegoś powodu ci sami przecież ludzie nie widzą przeszkód, by dorzucić kilka śmieci lub stłuc te kilka szyb więcej. Prawdopodobnym usprawiedliwieniem wydaje się być „przecież i tak dookoła jest już bałagan” albo

„wygląda na to, że inni tak robią, więc najwyraźniej nie ma w tym nic złego”

.

Jak się ma więc kryminał do wytwarzania oprogramowania? Czy programista może być porządnym człowiekiem i jednocześnie przestępcą? Może być, do tego zaskakująco często!
Jeśli oczyma wyobraźni przenieść by się z miejskiej dzielnicy do środowiska jakim jest duży projekt programistyczny, często prowadzony przez kilka lub kilkanaście osób (programistów, mieszkańców systemu), można z łatwością zaobserwować pewne analogie.

Jeżeli dany projekt jest prowadzony i zarządzany porządnie, przez profesjonalistów i konsekwentnie dąży on do kolejnego kamienia milowego to każdy obecny czy nowy uczestnik będzie starał się utrzymać lub nawet ulepszyć kod źródłowy pod względem jakości. Podobnie jak dom zbudowany na porządnych fundamentach wykazuje się mniejszym prawdpodobieństwem zawalenia w przyszłości. Każda zmiana będzie raczej przemyślana pod kątem całej architektury, kluczowe mechanizmy będą objęte odpowiednimi testami a nawet jeżeli znajdzie się ktoś, kto będzie próbował przemycić jakiś półprodukt, (np. hack skopiowany z google), jest wysokie prawdopodobieństwo, że główny programista czy nawet dobry test jednostkowy powstrzyma go lub pomoże mu go dostosować do poziomu. Główni programiści będą jednoczęśnie analogią do władz miasta, które dbają o swój interes.

Jeśli weźmiemy pod lupę inny projekt, który jest prowadzany bez motywacji lub jako element nudnej pracy przez co rusz innych ludzi każdego miesiąca (np. jest duża rotacja w jakiejś marnej firmie) to z czasem w kodzie źródłowym zaczną pojawiać się „wybite okna”, czyli w branżowej terminologii, smrody. (ang. code smells)
Każdy kolejny uczestnik projektu widząc obecny stan projektu będzie starał się tylko wykonać swoją pracę najmniejszym kosztem, bo

„to i tak nie jego własność”

czy też…

„płacą mi za dodawanie funkcji a nie poprawianie jakości, czegoś co i tak już było zepsute”

Jest to spory problem i często niedostrzegany przez kierujących projektem. Czas płynie swoim torem i w repozytorium pojawia się coraz więcej „wklejek ze stack’a” i innych gotowych, często leniwych rozwiązań. Wyobrażam sobie myśli osób pracujących na takim kodzie: „Jasne, że mogę przerobić ten fragment na szybko, nikt nie zauważy a poza tym ktoś już tak zrobił w innym pliku, a działać musi do poniedziałku”.

O testowaniu takiej funkcjonalności nawet nie ma co wspominać, bo często przez taki zlepek „smrodów” cierpi architektura projektu, czyniąc kluczowe mechanizmy trudne lub niemożliwe do odpowiedniego testowania. Tym sposobem z upływem czasu projekt staje się coraz bardziej skomplikowany, znienawidzony przez twórców, coraz trudniejszy do uporządkowania i w efekcie zostaje wypuszczony, o ile w ogóle, jako „średni”. Mam dziwne przeczucie, że tego typu przypadłość mogła się przytrafić przy powstawaniu jednej z popularnych rodzin systemów operacyjnych, ale to zupełnie inna historia.

Tak więc popierając postawioną wcześniej tezę, programista może być przestępcą, który będzie szkodził swojemu otoczeniu (w tym kontekście mowa jest kodzie źródłowym). Zwykle będzie miał ku temu tym większe skłonności, im gorszy stan będzie miało środowisko, w którym przyjdzie mu zaistnieć. W idealnym świecie każdy powinien w miarę możliwości dążyć do jakości i działać możliwie profesjonalnie niezależnie od sytuacji. Lecz z kolei w naszym realnym świecie warto przede wszystkim umieć trzeźwo ocenić sytuację i na czas dostrzec tytułowe rozbite okna w każdym kodzie źródłowym, z którym przyszło nam pracować.