Niekiedy napisanie programu od nowa jest lepszym wyjściem niż żmudne poprawianie linijka po linijce źle napisanego kodu. Od czego jednak zależy, która opcja jest lepsza? Często wystarczy dokładniej przyjrzeć się specyfice danego projektu.
Zacznijmy od bardzo konkretnego przykładu: firma wezwała na pomoc zewnętrznego programistę w momencie, gdy 95% pracy nad programem zostało już wykonane. Na tym etapie projekt znacznie wykraczał poza założony budżet, był mocno opóźniony, zaś zaangażowany w jego realizację zespół programistów nie miał najmniejszej ochoty nadal nad nim pracować. Nic zresztą dziwnego: po pobieżnych oględzinach okazało się, że był to jeden z najgorzej napisanych programów w historii.
Program miał zautomatyzować obsługę systemu przenośników składających się z serii powtarzalnych komponentów. Jego kod stanowił zbiór powtarzalnych sekwencji, z których każda przypisana była konkretnemu przenośnikowi. Tworzenie nowej sekwencji polegało głównie na skopiowaniu poprzedniej i zmianie nazw znaczników. Cała trudność polegała na tym, że każdy przenośnik pełnił nieco inną funkcję, więc każdą sekwencję należało zmodyfikować tak, by dopasować ją do owej funkcji. Łącznie program składał się ze 100 sekwencji i 50 szczebli źle skonstruowanej i podatnej na błędy logiki. W efekcie rzeczywiście generował błędy ? ok. 1% zaprogramowanych procesów przebiegało nie tak, jak powinno.
Utrzymanie i skalowalność na minusie
Podstawowym problemem w przypadku tego typu programów tworzonych z myślą o branży przemysłowej jest ich utrzymanie: jeśli programista nie jest obeznany z kodem, będzie musiał poświęcić całe godziny na zapoznanie się z nim i zrozumienie rządzącej nim logiki, zanim będzie mógł przystąpić do wprowadzania zmian i poprawek. A ponieważ programowanie przemysłowe ma to do siebie, że jest często ograniczone zasobami organizacyjnymi i strukturalnymi, większe projekty często są przygotowywane dosyć niechlujnie, co jeszcze utrudnia programiście zadanie.
Jeśli aplikacja jest trudna w utrzymaniu, będzie prawdopodobnie także trudno skalowalna. Wspomniany projekt zakładał, że w przyszłości system ulegnie dwu- lub trzykrotnej rozbudowie, co oznaczało, że program będzie musiał zostać rozszerzony o 200 nowych sekwencji. Oczywiście można je częściowo skopiować. To jednak dopiero połowa zadania: teraz przychodzi czas na żmudną edycję każdego znacznika. Nie trzeba być programistą, aby zrozumieć, że tego typu kod nie jest łatwy do rozwijania ? jest mało skalowalny, trudny w utrzymaniu, a dodatkowo nie do końca realizuje swoje funkcje. A biorąc pod uwagę, że napisanie go zajęło programistom kilka miesięcy, jego poprawienie może potrwać znacznie dłużej.
Naprawiać czy pisać od nowa?
Co najlepiej zrobić w takiej sytuacji? Debugowanie i optymalizacja istniejącego kodu zajmie zapewne mniej czasu, niż napisanie programu od nowa. Spora liczba koniecznych do wprowadzenia zmian nie daje jednak w tym przypadku gwarancji sukcesu, a rezultat nadal będzie odbiegał od oczekiwań, zwłaszcza w kwestii późniejszej rozbudowy.
Jak powiedział kiedyś John Woods ? programista komputerowy starej szkoły: ?Zawsze koduj tak, jakby twoją pracę miał przejąć brutalny psychopata, który wie, gdzie mieszkasz?. Cytat ten wyjątkowo trafnie oddaje opisaną tu sytuację i sugeruje, jaką decyzję należy podjąć. W tym przypadku programista zdecydował się napisać dużą część programu na nowo, wychodząc z założenia, że robiąc to dobrze, zaoszczędzi problemów kolejnym programistom zaangażowanym w projekt ? niezależnie od tego, czy będą oni wykazywać skłonności psychopatyczne, czy też nie.
Nie wszystko zostało jednak zmodyfikowane ? zgodnie z zasadą, że ?nie ma sensu naprawiać tego, co nie jest zepsute?. Nie manipulowano przy modułach I/O, gdyż sprzęt był odpowiednio podłączony i nie sprawiał problemów. Program antywirusowy działał sprawnie i był na tyle prosty w budowie, że nie trzeba było go optymalizować, podobnie jak kod odpowiadający za przełączanie między automatycznym i ręcznym trybem pracy. Programista skoncentrował się więc na zmianie głównego programu sterowania przenośnika, zachowując jednakże niektóre poprawnie przygotowane szczeble drabinki.
W tym przypadku decyzja o napisaniu dużej części programu na nowo okazała się słuszna: dzięki temu 3000 szczebli języka drabinkowego zastąpiono ok. 500, co znacznie zwiększyło przejrzystość programu, a jednocześnie ułatwiło jego utrzymanie i ograniczyło liczbę błędów. Całość prac zajęła co prawda niemal trzy tygodnie, ale obejmowała także przystosowanie systemu do przyszłej rozbudowy ? teraz można go powiększyć dwukrotnie, zmieniając jedynie kilka znaczników. Znacznie zwiększyło to elastyczność programu i uniezależniło klienta od jego twórcy. Dlatego jeśli koszty i czas na to pozwalają, zawsze lepiej jest napisać dany kod od nowa, niż na szybko poprawiać kilka linijek. Za jakiś czas ktoś i tak będzie musiał zrobić to we właściwy sposób.
David Breen jest głównym programistą w firmie Breen Machine Automation Services.
