Błąd. Dziura. Usterka. Codzienność z życia programisty. Wszystkim deweloperom na świecie te słowa są znajome, no, chyba że nie znają Polskiego, ale ja nie o tym :). Występowanie bugów jest naturalną składową tworzenia oprogramowania. Nie ma w tym nic złego, a problem pojawia się, dopiero gdy jest więcej błędów, a Ty nie jesteś w stanie nad nimi zapanować. Jak to wygląda i co jest jego przyczyną? Opisuję i objaśniam :)

Ten post jest częścią cyklu dotyczącego symptomów niezadbanego kodu. Lista powiązanych artykułów znajduje się we wstępnym poście.

Rodzaje upierdliwych błędów

Powiązany

Ruszasz jedno miejsce, a inne się sypią jak fabuła w Zagubionych. Jest to najgorsza z odmian, jaką możesz wyhodować. Jestem pewien, że jesteś w stanie przypomnieć sobie takową historię ze swojego programistycznego życia. Próbujesz naprawić błąd, ale rodzi to nowe usterki, których poprawa generuje jeszcze więcej dziur. Zdajesz sobie sprawę, że coś się tu nie skleja. Something is no yes, jak to mówią Anglicy!

Powracający

Zdecydowanie mniej destrukcyjny, ale dużo bardziej irytujący. Wraca do Ciebie jak Lessie do Joea. Ty poprawiasz, zadowolony komitujesz, odsyłasz na północ, zapominasz. Kilka tygodni później doświadczasz deżawu, widząc go ponownie. Naprawiasz po raz drugi, myśląc, że to sen. Tracisz jednak humor, widząc go ponownie i znów, i znów, i jeszcze raz.

Prosty

Ten rodzaj wydaje się nie być destrukcyjnym, dla klienta. Natomiast jest świetnym devindykatorem, występującym tylko tam, gdzie zrozumienie prostych reguł biznesowych jest trudne i czasochłonne. Aplikacja niby dobrze działa, ale cały czas wyskakują jakieś niedociągnięcia. Na tyle małe, że chciałbyś się je ignorować, lecz ich ilość i częstotliwość wyklucza takie rozwiązanie.

OK. Znamy najczęstsze błędy spowodowane niezadbanym kodem. Czas byśmy przyjrzeli się bliżej, nie symptomom, lecz powodom takiego zachowania.

Kiepska czytelność kodu

Najczęstszy powód upierdliwych błędów na świecie. Choć nieczytelny kod to indywidualna projekcja każdego programisty, to istnieją pewne wspólne elementy. Przykładowo:

  • Nic niemówiące nazwy zmiennych.
  • Łamanie zasad SOLID.
  • Zaszyte w kodzie stringi czy inty.

W czym to przeszkadza? Znalezienie jednej konkretnej ścieżki, powodującej błąd w takim kodzie jest trudne, gdy musimy porównywać nic niemówiące zmienne z zahardkodowanymi stringami. Nie da się tego zrobić w rozsądnym czasie w taki sposób, by mieć pewność, że nic innego się nie popsuło.

Nieporządkowana złożoność

To trzeba hodować miesiącami. Zazwyczaj ma postać nie tyle olbrzymiej klasy, ile ogromnej funkcji, mającej setki, a czasem tysiące linii kodu. Ze względu na rozmiar zawiera wiele deklaracji, przypisań, warunków i pętli. Pomimo w miarę dobrze nazwanych zmiennych, skala czyni ją niezrozumiałą. Zasieki ifów zwiększają złożoność cyklomatyczną do horrendalnych wartości, nie ułatwiając tym samym analizy. Jeżeli nie jesteś w stanie opisać, zdaniem prostym, co dana funkcja robi. Nie powinien Cię dziwić fakt, że jakiś robal, schowany z ciemnym kącie tego kolosa, umknie przed Twoim wzrokiem.

Tajemnicze zależności

Czym jest architektura? Można by się długo rozwodzić, ale pisał już o tym Uncle Bob w książce „Czysta Architektura”. Na potrzeby tego wpisu załóżmy, że jest to ogólna struktura aplikacji, wysokopoziomowo przedstawiająca, gdzie co jest. Gorzej, gdy takiej struktury nie ma lub jest nienazywalna niczym Voldemort.

W takiej sytuacji nie sposób określić zależności pomiędzy klasami. Każda używa każdej, co tworzy cykliczne zależności. Powoduje to brak zrozumienia odpowiedzialności poszczególnych klas oraz ich powiązań. W związku, z czym zmiana pojedynczego elementu może spowodować zmiany, a co za tym idzie, również bugi, w zupełnie innej części systemu.

Co teraz?

Skoro brudny kod może być przyczyną tylu błędów to, co można z tym zrobić? Moja rada jest prosta. Zrefaktorować! Uważasz, że się nie da, bo coś jest zbyt duże i zbyt skomplikowane? Jeżeli tak to tym bardziej się tym zajmij. Pamiętaj, że refaktoring to nie żadne czary, a szereg malutkich kroczków czyniących kod lepszym i prostszym, czyli mniej podatnym na błędy. Jeżeli nie wiesz jak się do tego zabrać, to polecam Ci wpis 9 porad, które pomogą naprawić Twój kod.

Na koniec

Zgadasz się ze mną? Gadam głupoty? Coś pominąłem? A może wiedza z Tego wpisu pobudziła Cię do przemyśleń? Daj znać! Czekam niecierpliwie na Twój komentarz.



Podobało Ci się?

Zapisz się i nie przegap kolejnych postów.


3 Komentarze

Marcin Bębenek · 2018-10-13 o 12:41

Napisany przyjemnym lekkim do czytania językiem. Brawo Jurek. Mam jeszcze jeden pomysł, na opis błędu choć nie potrafię go dobrze nazwać. Czasem bądź częściej zdarza się programiści chcą naprawić błąd w niewłaściwe warstwie np. błąd który występuje w API chcą naprawić we frontendzie. Lub błąd logiki biznesowej w kontrolerze. Spotkać to można często jak programiści są podzieleni w zespołach warstwowych aplikacji i nie mają dobrej komunikacji. Czy ma to sens?

    Jerzy Wickowski · 2018-10-14 o 00:18

    Hej Marcin.
    Dziękuję ślicznie za miłe słowa :). Co do tego typu błędu jaki opisujesz to jak najbardziej uważam, że jest problematyczny, gdyż każda taka zmiana obniża czytelność, ale czy jest to związana bezpośrednio z brudnym kodem? Z jednak strony to raczej problem komunikacyjny, tak jak Ty to zidentyfikowałeś. Z drugiej strony, czy skoro ktoś próbuje załatać błąd API na frontendzie to z jakiego powodu? Jest kiepskim programistą, czy rzeczywiście kod jest w takim stanie, że nie wiadomo co gdzie jest.

Jakub Wierzbanowski · 2018-10-16 o 10:12

Kiedyś miałem styczność z bardzo brudnym kodem, 3 dni schodziło na to żeby przekopać się przez część systemu, tylko po to żeby poprawić jedną linijkę w kodzie :) Bardzo dużo można nauczyć się pracując z brudnym kodem, szczególnie można się nauczyć jak nie pisać kodu, jak ktoś wyciągnie odpowiednie wnioski to na pewno zwiększy swoją wiedzę.

Dodaj komentarz

Twój adres email nie zostanie opublikowany.

This site uses Akismet to reduce spam. Learn how your comment data is processed.