Źródła błędów w projektach programistycznych

Niniejszy artykuł powstał w wyniku obserwacji, które dokonuje od dłuższego czasu, uczestnicząc przy różnego rodzaju software-owych projektach informatycznych. Napisany jest z punktu widzenia programisty, czyli osoby, która ma największą styczność z nimi.

Błędy w oprogramowaniu są rzeczą niemożliwą do uniknięcia, jednakże znając ich przyczyny i poniekąd skutki można im w pewnym stopniu zaradzić. Postaram się przybliżyć każdy z rodzajów błędów oraz podać możliwe przyczyny i jeżeli to możliwe – rozwiązania.

Rodzaje błędów:

błąd w kodzie – zwykle niezbyt poważny i łatwy do naprawy, jest to błąd w rodzaju literówki lub użycia niesprawdzonej zmiennej, która okazuje się mieć inny typ niż zakładamy, błędy tego typu spotyka się najczęściej w niechlujnie napisanym kodzie czyli pisanym przez roztargnionego/zmęczonego/poganianego programistę (niepotrzebne skreślić), panaceum na tego typu błędy jest dobre IDE (literówki) oraz wypoczęty i uśmiechnięty programista

błąd niezrozumienia kodu zwany też WTF– błąd dla odmiany bardzo poważny, sprowadza się do tego, że programista zwykle dostając kod po kimś innym lub wracając do swojego starego kodu nie wie o co w nim chodzi – metody z milionem warunków albo wszystkomające klasy – są to rzeczy nie do ogarnięcia.

Rozwiązania są trzy,

  1. krótkoterminowe przydzielać programistom pewne części systemu, którymi tylko oni się zajmują,
  2. zastosować extreme programming (drugi programista na bieżąco przegląda kod),
  3. zatrudnić architekta, który ustali standardy pisania kodu oraz będzie je wymuszał przez przeglądanie kodu

błędy regresji – najbardziej paskudny z rodzajów błędów, pojawiają się gdy beztrosko robimy nową funkcjonalność lub naprawiamy jakiś mały błąd nie będąc do końca świadomym powiązań w kodzie, jedynym rozwiązaniem tego błędu jest stosowanie wszelkiej maści testów automatycznych (jednostkowych, funkcjonalnych) które pozwolą nam przetestować powiązania z innym kodem w rozsądnym czasie

błąd projektowania – nieprzemyślana architektura systemu prowadzi do chaosu w kodzie, który powoduje m.in. dwa wcześniej wymienione błędy, głównym powodem tego stanu rzeczy jest nagminne stosowanie metodologi Kopijego-Pejsta i rozrost kodu do monstrualnych rozmiarów, którego nikt nie jest w stanie ogarnąć, rozwiązaniem jest zatrudnienie doświadczonego programisty/architekta w zależności od wielkości projektu

błędy komunikacji – niezrozumienie między klientem – project managerem – programistą, czyli klasyczny głuchy telefon, klient chciał bułkę z serem, project manager zrozumiał że z selerem a programista, że miał to być tost ;P , częstym powodem tego typu błędów jest niespójność terminologii używanej przez te trzy kategorie osób,

przykład z życia: klient – osoby kontaktowe, project manager – klienci, programista – użytkownicy

stosowanie spójnej terminologii i ustalenie pojęć jest podstawą do zakończenia (skomplikowanego) projektu z sukcesem, dobra praktyką jest nazywanie metod/funkcji według zadań, które klient chce aby system wykonywał

błąd wyboru technologii – wbrew pozorom zdarza się dość często (wg mnie), zwykle firmy przyzwyczajone są do pewnego rodzaju technologii i raczej starają się nagiąć problem do technologii niż na odwrót, rzadko kto zmieni kompletnie technologię dla jednego projektu, ponieważ zwykle jest to ekonomicznie nieuzasadnione (przynajmniej w krótkim terminie) zwykle rezultatem tego błędu są problemy w implementacji systemu i zwykle powolne jego działanie, rozwiązaniem jest dokładne rozeznanie przed rozpoczęciem projektu

błąd w oszacowaniu czasu trwania projektu – z praktyki wynika, że rzadko, który projekt informatyczny kończy się w zakładanym terminie, a czym mniej znana jest dziedzina w której jest prowadzony tym większe prawdopodobieństwa grubego przekroczenia terminu. Niestety ten błąd jest źródłem wielu innych. Nie ma łatwego do zastosowania panaceum na ten błąd, nawet doświadczony PM mający do czynienia z wieloma różnymi projektami nie będzie zawsze w stanie dobrze określić terminu zakończenia prac, do którego trzeba jeszcze dodać przeróżne wypadki losowe (choroba pracowników, kataklizmy etc)

błąd nieoznaczoności klienta – klient zawsze chciałby coś zmienić i zwykle najważniejszego dla niego rzeczy są dla nas najmniej istotne. Klienta temperować powinien PM, którego zadaniem jest unicestwiać szalone pomysły klienta nim trafią do nas, pewnym zabezpieczeniem jest też dokładna, parafowana przez obie strony specyfikacja,

Podsumowując, w zależności od stopnia złożoności projektu pojawiają się inne rodzaje błędów. Obserwując tworzone m.in. prze zemnie oprogramowanie dochodzę do wniosku, że wraz ze wzrostem złożoności projektu większą role zaczyna odgrywać zarządzanie nim. Poczynając od dobrych założeń architektury, poprzez bieżące przeglądanie kodu i przymuszanie do standardów oraz spójny język z klientem. Dlatego każdy kto poważnie myśli o tworzeniu złożonego oprogramowania powinien wziąć pod uwagę wszystkie wymienione błędy i jak najszybciej im zapobiegać ponieważ każdy z nich może łatwo i szybko uśmiercić nawet najlepiej zapowiadający się projekt.

Leave a Reply

Informuj mnie o odpowiedziach poprzez e-mail. Możesz również subskrybować wpis bez zostawiania komentarza.