Pewnie nie raz słyszeliście, że istotne jest, by zachować
dobre praktyki i wzorce projektowe. Dlaczego jednak jest aż tak ważne, po co „marnować”
dodatkowo czas po to, by stosować się do tych reguł?
Zdobywałem doświadczenie przy bardzo dużym projekcie, który
jest rozwijany już lata i z tego co wiem, wciąż się trzyma i nadal się rozrasta.
Dzięki temu, że właśnie tam stawiałem swoje pierwsze kroki jako programista,
mogłem od razu uczyć się programowania na całkiem dobrze napisanym projekcie.
Zanim jednak opowiem o tym dlaczego „Clean Code” miał znaczenie tam, zacznę od
spraw ogólnych.
Każda branża specjalistów ma specyficzny dla siebie język,
którego używa, by opisać swoją pracę bądź napotykane problemy. Weźmy na przykład
budowanie domu. Dom składa się z wielu
elementów instalacji i elementów, które trzeba stworzyć, by ktoś mógł w nim
zamieszkać i by sprostał oczekiwaniom właścicieli. W budynku możemy wyznaczyć
różne komponenty, jednak większość z nich zbudowana jest na bazie już
funkcjonujących schematów, bo wymyślanie wszystkiego od podstaw jest znacznie
droższe. Istnieją gotowe rozwiązania problemów, które budowniczy mogą napotkać,
schematy są sformułowane w taki sposób, że nawet gdy inny specjalista spojrzy
na to, co zrobił jego poprzednik, będzie potrafił dość szybko się odnaleźć w
danej konstrukcji. Są jednak ludzie, którzy wykonują swoją pracę niechlujnie i
niedbale. Tworzą elementy domu „na skróty”, chcąc w teorii zaoszczędzić. Np. elektryk
kładący instalację elektryczną, podpiął pod jeden bezpiecznik zbyt dużo kabli lub
(lekka skrajność, aczkolwiek sam widziałem tego typu „oszczędność”) przewody po
ścianach nie były kładzione pod kątem prostym tak jak każdy inny elektryk by
się spodziewał, tylko tak, by zużyć jak najmniej kabla… Brzmi absurdalnie
prawa?
Odnieśmy to teraz do naszej branży. Gdy stosujemy się do
dobrych praktyk, to tak, jakbyśmy pisali kod zgodnie ze znanymi schematami.
Jeżeli możemy, korzystajmy z gotowych rozwiązań problemów nazwanych wzorcami
projektowymi. Dzięki temu, gdy ktoś inny spojrzy na to rozwiązanie, zobaczy, że
został użyty wzorzec fabryki i od razu będzie wiedział czego może oczekiwać. A
jeśli nie wie co to właściwie jest ta fabryka, bardzo łatwo może znaleźć opis wzorca
w sieci. Pisząc kod nietypowy, w którym trzeba tworzyć wszystko od zera i idąc
na skróty sprawiamy, że całego modułu robiącego daną rzecz będzie nam bardzo trudno
ponownie użyć w innym miejscu. Gdyby cały kod został napisany zgodnie z dobrymi
praktykami, łatwo moglibyśmy wydzielić go z aplikacji i re-użyć gdzie indziej. Złudna
korzyść w postaci zaoszczędzenia czasu na początku, okazuje się dwukrotnie
bardziej czasochłonna podczas późniejszego pisania. Kod, który jest pisany na
szybko i niechlujnie, bywa też niezrozumiały dla kogoś innego, a przecież
przeważnie nad projektem pracuje cały zespół. Tak jak żaden elektryk nie
spodziewa się, że kable mogą iść pod różnymi kątami, tak programiści nie
spodziewają się, że zmiana logiki „dziwnego kodu” spowoduje wybuch w innej
części aplikacji. A to bardzo częste w podejrzanej czystości kodzie. Dobrze
napisany kod ma jeszcze jedną, bardzo ważną zaletę. Jest łatwy w testowaniu.
Możemy wydzielić moduły z kodu i testować je w izolacji. Możemy też spiąć je w
jeden komponent i sprawdzić jak one działają razem. Nazywamy to testami
jednostkowymi i integracyjnymi.
Projekt, o którym pisałem na początku nie jest oczywiście
ideałem. Miał bardzo wiele swoich problemów i nie wszystkie jego części były
dobrze napisane. Jednak jego podstawy i fundamenty były naprawdę solidne.
Dzięki zastosowaniu wzorców projektowych i pisaniu „czystego kodu” projekt był
rozwijany przez lata bez większych problemów. Te konkretne podstawy umożliwiły
ciągły rozwój aplikacji przez lata. Na temat dobrych praktyk programowania
można napisać znacznie więcej (polecam książkę „Clean Code” Roberta Martina),
jednak cel mojego postu to bardziej zainteresowanie tematem niż szczegółowe opisanie
problemu. A Ty jakie masz doświadczenie jeśli chodzi o czysty kod i dobre
praktyki?
Brak komentarzy:
Prześlij komentarz