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.