5-grzechów-glownych-programisty

Jesteś programistą? Developerem? Software Engineer? Tytuł nie ma znaczenia – zajmujesz się programowaniem i jesteś w tym dobry? Nawet najlepszym zdarzają się wpadki czy pomyłki – grzechy popełniane przy pisaniu kodu.

Niektóre zależą od nas, inne z kolei są wynikiem nacisku ‚góry’ – na szczęście z większością da się walczyć. Przejdźmy więc do konkretów, a po przeczytaniu tego wpisu możliwe, że nadejdzie chwila na refleksję.

#1 Wykomentuję ten kod, przyda się później

Chyba każdy z nas popełnił kiedyś ten błąd. Po wprowadzeniu zmian do aplikacji, zostawił wykomentowany stary kod. Nie ma problemu jeśli komentarz zostanie skasowany przed wysłaniem zmian do repozytorium, w innym zaś przypadku… Cóż, prawdopodobnie komentarz ten zostanie na zawsze, inni programiści będą bali się go usunąć – łącznie z autorem, który po krótkim czasie zapomni czemu to zrobił. Komentarz będzie zaciemniał kod, dodawał mu nowe znaczenie i zawsze powodował lekki wstrząs przy pierwszym natknięciu się na niego – słowem będzie to wrzód na…

Rozwiązaniem jest uwierzenie w systemy kontroli wersji. Nie musimy komentować kodu bo będziemy mieli dostęp do wcześniejszych zmian w naszym repozytorium. Z tego samego powodu nie powinniśmy się bać usuwać komentarzy.

#2 Napiszę ten kod jak najszybciej, w końcu są terminy

Najczęstszy problem tworzenia brzydkiego kodu – terminy. Wymówka jest prosta – zrobiłem, działa to wrzucam do repozytorium i biorę kolejne zadanie bo PM/PO/itp. wymaga. Po paru latach tego rodzaju pisania aplikacji, projekt jest często dobrym przykładem łamania zasad SOLID oraz miejscem zsyłki niepokornych programistów.

Rozwiązanie wymaga odrobinę odwagi – należy pamiętać, co jest naszą pracą. Menedżer pilnuje by produkt powstał na czas i działał prawidłowo – to jego zadanie. Naszym, jako programistów, jest dostarczenie wysokiej jakości kodu, który będzie działał prawidłowo. Można porównać nas do górników – szef kopalni chce byśmy szybciej kopali głębiej – możemy zrezygnować z umieszczania stempli. Jednak jeśli to zrobimy w pewnym momencie wszystko runie. Zatem brońcie z pasją czasu przeznaczonego na zapewnianie wysokiej jakości w kodzie.

#3 Testy napisze się później

Bardzo podobny błąd do poprzedniego, może być wręcz jego następstwem. Pojawia się też gdy wprowadzony zostaje TDD i nie wszyscy załapią jego rytm – będą dalej na pierwszym miejscu pisali kod, a potem… no właśnie, co potem? Kod działa, historyjka jest zaakceptowana. Test napiszę jak będzie wolna chwila, teraz biorę się za następne zadanie.

Testy są bardzo ważnym elementem zdrowego produktu. Ich pisanie wymusza trzymania się pewnych reguł oraz ułatwia wykrywanie błędów w pozostałych (np. Single-Responsibility Principle). Poza tym testy pomagają wprowadzać zmiany i wykrywać błędy. Jeśli przekonamy się o tym (co się stanie jeśli zaczniemy je pisać ;)) znacznie łatwiej będzie nam pilnować siebie oraz innych by powstawały. Warto również zainwestować w narzędzie do sprawdzania pokrycia testami projektu.

#4 A po co używać DI? Nigdy nie zmienimy bazy danych

Grzech popełniany szczególnie przy powstawaniu nowych projektów. Programiści nie chcą tracić czasu na tworzenie interfejsów, wstrzykiwanie zależności, bo wymagania obecne mówią jasno – będziemy korzystali tylko z bazy MS SQL. Po co się więc trudzić i opakowywać coś, co teoretycznie zawsze będziemy używać?

Warto, ponieważ nic nie jest pewne – klient może zmienić zdanie, twórca silnika bazy danych może zarzucić dla niego wsparcie, może wyjść nowa wersja silnika. Poza tym bez wstrzykiwania zależności nie będziemy w stanie tworzyć testów dla projektu.

#5 Trzeba się dostosować do standardów, co z tego że są złe?

Muszę zaimplementować nową metodę do repozytorium. Cóż, spojrzę jak jest robione gdzie indziej, skopiuję i dostosuję do danych jakie muszę wyciągnać/włożyć. Nie będę zastanawiał się nad sensem rozwiązań już użytych – po prostu ich użyję. Ci, którzy pracowali w starym kodzie, zapewne wiedzą o czym piszę.

Nawet jeśli tego nie zrobiliście mogę się założyć, że pokusa była spora. A potem? Potem kod tworzony miesiąc temu przypomina bagno w jakim jest projekt od 2 lat.

Rozwiązaniem powinny być dokładne code reviews oraz prosta zasada – jeśli dodajemy naszą funkcjonalność do projektu, to powinniśmy napisać ją zgodnie z zasadami dobrego kodu (np. SOLID) oraz chociaż w małym stopniu posprzątać okolicę. Dzięki temu zamiast degradacji kodu możliwe, że polepszymy jego jakość!

Powyższy wpis piętnuje pewne zachowania oraz proponuje sposoby ich rozwiązań. Nie zostały tu wymienione wszystkie grzechy programistów, nie ma też w pełni opisanych zasad pisania czystego kodu. Zainteresowanych tymi tematami odsyłam do książek Roberta Martina, w szczególności „Clean Code”.

Myślisz, że ten wpis pomoże Twoim znajomym programistom unikać błędów? Podziel się z nimi treścią artykułu.