Łam zasady świadomie

Łamanie pewnych konwencji i zasad jest proste jeśli ich nie znamy. W końcu ciężko trzymać się czegoś o czym nie mamy pojęcia. Czy jednak znając dobre praktyki powinniśmy się ich zawsze trzymać? A może warto czasami świadomie pójść w drugą stronę? Tekst jest właściwie tylko krótkim przemyśleniem i nie będę się tutaj rozpisywał. Mam nadzieję, że to o czym mówię jest dla większości z Was oczywistością :)

Na pewno ucząc się pewnych technik programowania jak np. TDD masz w głowie myśl typu „jak mogłem tego nie znać? Od teraz będę się zawsze trzymał tego w każdym projekcie”. Dostrzegasz zalety czegoś czego wcześniej nie znałeś. I zaczynasz je z uporem maniaka wprowadzać w życie. Jak to mówią „mając młotek wszystko staje się gwoździem”. W tym momencie jesteś na drugim etapie poznania – bezrefleksyjnym korzystaniu z wiedzy. Pierwszym etapem była niewiedza i nauka. Jednak jest też kolejny – świadome łamanie zasad.

Waląc tym swoim młotkiem przez jakiś czas ślepo podążasz przed siebie. Nagle każdy twój projekt zaczyna być pisany z użyciem TDD, DDD, wszelkim znanych wzorców projektowych i udokumentowany co do jednej metody. Nieważne, że jest to projekt na uczelnię i wstępnie mógłby zająć jakieś pół dnia. Jesteś szczęśliwy, że udało Ci się go zrobić „zgodnie ze sztuką” mimo, że zajęło to tydzień. Nadchodzi jednak moment kiedy mówisz albo słyszysz „stop”. Często ten moment przychodzi w pracy kiedy świadomie trzeba zrezygnować z jakiegoś czystego podejścia, żeby móc zrobić coś optymalnie. Ewentualnie są fragmenty, przy których wiadomo, że nie pożyją długo. W takim wypadku pisanie wszystkiego zgodnie z zaleceniami z mądrych książek mija się z celem skoro dany kod wyleci najpóźniej za miesiąc. Tak samo jest z projektami testowymi czy studenckimi.

Jednak co jest ważne w łamaniu zasad to to, żeby potrafić podać sensowny argument przeciwko. Nie masz zamiaru używać pełnego SOLIDa? Ok, tylko powiedz dlaczego wybierasz takie podejście. O dziwo argumenty za tym można znaleźć, wymaga to jednak doświadczenia i obeznania z porzucanymi rozwiązaniami. Naucz się korzystać z młotka, żeby potem móc powiedzieć dlaczego nie chcesz go użyć mając śrubę zamiast gwoździa.