Teoria rozbitych okien

Opublikowano przez

„koncepcja w kryminologii i socjologii miasta zakładająca, że brak reakcji na łamanie mniej ważnych norm społecznych, np. tłuczenia szyb w oknach w danej dzielnicy, sprzyja wzrostowi przestępczości i łamaniu innych norm na zasadzie zaraźliwości.” (pl.wikipedia.org)

​

Broken windows

Mówiąc krótko jeśli w otoczeniu jest bałagan, wandalizm to tendencja do łamania norm społecznych zwiększa się. Brzmi znajomo? Pewnie każdy z nas spotkał się z widokiem takich osiedli, budynków itp. Czy na co dzień my jako programiści spotykamy się z tym problemem w pracy? Jak najbardziej! Taka dzielnica to może być nasza aplikacja a budynek projektem, modułem. A akty wandalizmu? Nieczytelny kod, mieszanie różnych notacji, brak obiektowości, łamanie różnych zasad solid, dry, kiss itd. Można by wymieniać wiele takich „grzeszków” programistów ale chyba największym z nich jest przyzwolenie na ich powielanie zgodnie z zasadą, że skoro i tak już jest bałagan, to moja zła zmiana wiele więcej nie popsuje. Często  jest to także związane z tym, że przystosowujemy się do otoczenia i jest ogólne przyzwolenie na taki stan. Jest jak jest, po co zmieniać … Ale wiemy do czego takie podejście prowadzi.

 

​

Temporary fix



Drobna poprawka do kodu

Otrzymujesz zadanie wprowadzenia drobnej poprawki do kodu. Znalazłeś już klasę, metodę do zmiany. Przeglądasz istniejący kod i w tym momencie dość często stajesz przed wyborem czy wykonać ją tak aby zostawić jak najmniej zmian i mieć problem z głowy czy dokonać przy okazji drobnej refaktoryzacji. Ja stosuje zasadę „pozostaw kod lepszym niż go zastałeś”. To mogą być naprawdę drobne rzeczy, które można zrobić „przy okazji” i często są one automatyzowane przez IDE, np.:

  • usunięcie zbędnych pustych linii, poprawienie wcięć
  • usunięcie referencji do nieużywanych modułów
  • usunięcie zbędnych komentarzy
  • usunięcie nieużywanego kodu

Kolejny przykład z jakim spotykam się na co dzień to notacja węgierska. Projekt ma kilka lat i tak od początku był pisany. Ale zasady się zmieniły, dziś już jej nie stosujemy. Więc jeśli trafiam w miejsce gdzie występuje i mam wprowadzić tam zmiany to nie rozbijam kolejnego okna tylko piszę nowy kod wg nowych zasad.

Nie było testów

Dodajesz lub modyfikujesz metodę i widzisz, że nie posiada ona testów jednostkowych to dodaje je. Nowa klasa? tym bardziej! To, że do tej pory niektórzy ich nie pisali nie oznacza, że masz być kolejnym „wandalem”.

Podsumowując

Czasem trudno jest wyłamać się i zacząć wprowadzać zmiany. Jeśli nie czujesz się na siłach poproś o pomoc team leadera. Uważaj także aby nie stać się przez przypadek rewolucjonistą i nie dokonać przewrotu w projekcie. Pamiętaj „small changes can make a big difference”