5 kroków do zagłady – wstęp

Wszyscy którzy śledzą moje materiały, które publikuję w ostatnim czasie zarówno na blogu jak i na kanale na Youtube widzą na pewno, że większość z nich ma jeden wspólny punkt. Jest nim jakość kodu. Jest to coś na czym postanowiłem się skupić w swoim rozwoju jako programista.

Z tego powodu chcę też Wam pokazać, że warto o takie rzeczy dbać. Stąd powstał pomysł na nową mini-serię. Tym razem jednak akcja będzie większa bo publikuję materiały zarówno tutaj jak i na kanale na Youtube. Dotyczą one tego samego tematu jednak dają możliwość dotarcia do większej grupy ludzi. W końcu nie każdy lubi czytać takie treści tak samo jak nie wszyscy mają ochotę słuchać jak ktoś na ten temat opowiada.

Cykl życia błędu

Rozmyślając nad konkretną tematyką w końcu znalazłem listę tematów, które mam zamiar poruszyć. Co więcej dosyć dobrze łączą się one ze sobą pokazując kolejne fazy powstawania słabego kodu. Niby niegroźnie wyglądające na początku rzeczy. Coś co na pewno jest na chwilę albo co „nie przeszkadza nam” lub „tak nam jest wygodniej”.

Absolutnie nie jest to pełna lista! Ba! Nie jest ona nawet blisko pełnej listy. Dlatego zachęcam Was do dzielenia się w komentarzach tym co w Waszych projektach okazało się zgubne w skutkach mimo, że na początku wydawało się niegroźne.

Są to wybrane przeze mnie elementy, która są praktycznie zawsze początkiem mniejszej lub większej tragedii. Przyjrzyjmy się więc o czym będzie rozmowa w kolejnych tygodniach. W następnych materiałach poniższe problemy przeanalizujemy, dowiemy się jakie konsekwencje za sobą niosą i sprawdzimy jak można im zapobiec albo je rozwiązać.

Na razie to tu zostawię

Bardzo powszechna sytuacja. Piszemy jakąś funkcjonalność. I dla wygody zaczynamy od wrzucania wszystkiego do jednej funkcji. Bo na razie nie jest pewne co zostanie. A bo na razie nie jest pewne jak to najlepiej podzielić. Teraz tylko chcemy sprawdzić czy w ogóle pomysł działa. Powodów jest wiele. Podzielimy całość później.

I to później jakoś ciągle się przesuwa. Aż staje się klasycznym „jutro”. A nasz kod zaczyna składać się z ogromnych, wszystkorobiących funkcji. W końcu dzięki temu cała funkcjonalność jest w jednym miejscu, a nie rozrzucona po klasach, prawda?

Wiadomość dla potomnych

Skoro kod nam się trochę skomplikował to trzeba go udokumentować! W końcu nie chcemy żeby kolejne osoby, które tu będą zaglądać myślały, że nie wiemy co robimy. Przecież doskonale wiadomo co ten kod robi. Komentarz to tylko wiadomość dla przyszłych odwiedzających.

Skoro już pokazaliśmy innym co dzieje się w naszym kodzie to teraz pora na profesjonalne podejście do pracy z kodem. Każda poważna biblioteka ma udokumentowane funkcje, z których możemy korzystać. Dlaczego nasz kod ma być mniej profesjonalny? Trzeba okomentować każdą funkcję! Dzięki temu praca w zespole będzie jeszcze przyjemniejsza.

A jak coś się zmieni to wystarczy aktualizować komentarze. Proste, prawda?

Każde pokolenie ma własny kod

Kod już nam się mocno rozrósł. Do tego całość tworzy mocną, zwartą konstrukcję. Jednak potrzebujemy zrobić krok naprzód i zmienić zachowanie jednego elementu. Wszędzie korzystamy z konkretnych klas bo przecież doskonale wiedzieliśmy co robimy więc po co zakładać za dużą elastyczność. Poza tym nie potrzebujemy zmieniać całości tylko chcemy żeby jedna z funkcji w klasie zachowywała się inaczej! Więc nie przesadzajmy. Wystarczy odziedziczyć, zostawić większość funkcji bez zmian nadpisując jedną. O to przecież chodzi w programowaniu obiektowym. Przynajmniej mamy pewność, że niczego w innym miejscu nie zepsuliśmy.

Jedna ściana więcej, dla pewności

Kiedy mamy kod, który elegancko realizuje plan wielopokoleniowej rodziny i sprytnie zamknęliśmy wszystko co potrzebne dla funkcjonalności w pojedynczych funkcjach (dzięki temu nie trzeba niczego szukać w wielu plikach) to brakuje tylko jednej rzeczy. Przecież nasz kod to nie byle Hello World tylko poważna aplikacja biznesowa. A zasady są takie, że trzeba dzielić kod na warstwy. Trzeba oddzielić dostęp do danych od frontendu! Do tego trzeba mieć warstwę sprawdzającą czy dane, które przyszły są poprawne. Nie możemy też łączyć encji bazy danych z tym co zwracamy w innych warstwach. Skoro musimy w niektórych miejscach zwrócić dane z kilku tabel to też nie będziemy tego robili jak dzikusy gdzieś blisko widoku.

Nie wiadomo jednak co w przyszłości będzie chciał robić biznes więc kod powinien być konfigurowalny. Na szczęście korzystaliśmy z dziedziczenia. Więc wystarczy odpowiednia warstwa, która sprawdzi konfigurację i wybierze klasy jakich potrzebujemy. Tak się pracuje w prawdziwej korporacji!

Spokojnie, wiem co robię

Zatrudniają nas zakładając, że wiemy co robimy. Do tego nasz kod idealnie pasuje do wymagań biznesowych. Co może być nie tak? Są w firmie testerzy więc niech już mają jakaś pracę także pozwalamy im testować to co robimy. Ale wiemy, że to tylko formalność. W dodatku znajomość każdego kawałka kodu to oczywistość. Z resztą wszystko mamy opatrzone komentarzami. Do tego korzystamy z najważniejszej funkcji języków obiektowych czyli dziedziczenia, dzięki temu nigdy nie psujemy tego co już działało. Zmiany w logice niestety są czasami potrzebne, ale przecież to tylko kilka linijek. Wszystko jest pod kontrolą.

Wniosek jest prosty – testy to tylko strata czasu. Niech je sobie piszą ci, którzy nie są pewni swoich umiejętności. Bo po co inaczej pisać kod, który nie przynosi wartości? W korporacji nie ma miejsca na zabawę. To poważna praca, która ma dawać poważne pieniądze.

Do tego musielibyśmy łamać zasady, których się trzymamy pisząc kod tylko po to żeby można było napisać testy? Absurd.

 

Nie przegap!

Jeżeli zainteresowała Cię tematyka to świetnie. Wiedz, że kolejne wpisy z tej serii będą pojawiały się co tydzień w niedzielę. Równolegle także dodawać będę na kanale na Youtubie materiały wideo, w razie jakby ktoś wolał o tym słuchać zamiast czytać. Żeby nie przegapić następnej części i mieć zawsze najnowsze informacje o publikacji zachęcam do polubienia strony na Facebooku. Tam też będziesz mógł dzielić się swoimi wrażeniami.