… nic w sensie utrzymania.

Odpowiedź jest bardzo prosta. Kod o stabilnych wymaganiach. Nie jest wtedy istotna jakość kodu. Jeżeli potrafimy zapewnić stabilne wymagania to kod po początkowym, mniej lub bardziej bolesnym, okresie „docierania” nie będzie wymagał napraw.

Co mam na poparcie tej tezy?

Popatrzcie wokół siebie. Kod nieutrzymywany, bo niezmienny, bo posiadający stałe i niezmienne wymagania jest wokół was. Mikrofalówka prędzej padnie z przyczyn elektrycznych niż informatycznych. Tak samo pralka. Dla przypomnienia Java to miał być język do programowania AGD. Kod o stabilnych, niezmiennych wymaganiach nie wymaga konserwacji, a zatem koszty jego utrzymania są równe zero.

To dlaczego mój kod kosztuje

Jest kilka powodów.

Zmiana wymagań

Zazwyczaj już po wdrożeniu. Zazwyczaj zmiany w kodzie są wtedy robione na szybko, przez programistów z supportu, którzy powiedzmy szczerze nie są od tego 🙂 Zmiany powodują nieznany wpływ na inne części systemu, co w dłuższym czasie owocuje pojawianiem się różnych bugów.

Niestabilność projektu

Która w połączeniu z tendencją do nie nanoszenia zmian w harmonogramach powoduje, że pojawiają się różne potworki.

Nowe funkcjonalności

Trochę jak zmiana wymagań. Tyle tylko, że diabli wiedzą co popsują i dlaczego. Nowy kod jest niewiadomą. O ile w przypadku całkowicie nowych funkcji mamy pewne wyobrażenie do czego się wpinamy i wiemy jak to zrobić, to zazwyczaj dodawanie funkcjonalności przez integrację jest już trudniejsze. Prostym i niestety często spotykanym przykładem jest dodanie nowej biblioteki, która wymaga zamiast log4j 1.2.13 wersji 1.2.15. Ta mała zmiana powoduje, że trzeba ciągnąć JMXa…

Dopuszczanie gówna

Szczególnie widoczne jeżeli działamy w modelu klient-serwis, gdzie wystawiamy jakąś usługę, a klienci mogą pisać własny soft. Zazwyczaj mają tendencję do pisania kiepskich klientów, a nasze założenia co do zgodności biorą w łeb. Ważna zasada – jeżeli tworzysz soft, który ma działać w takim modelu to pamiętaj by nie zakładać żadnych sprawdzeń po stronie klienta. Walidację robisz po swojej stronie i jak najwcześniej by w razie czego zionąć błędem. Nie ma nic gorszego niż klient, który ma tendencję do wpuszczania nam do systemu jakiś komunikatów powodujących awarie.
Ważnym elementem jest tu dokumentacja i bardzo rygorystyczne testy zgodności.

Wnioski

Serwisowanie kodu kosztuje wtedy gdy musi być on zmieniany. Jeżeli założymy, że w większości przypadków jedyną niezmienną rzeczą w projekcie są zmiany to wtedy kod kiepskiej jakości będzie pociągał za sobą koszty. Jeżeli po wdrożeniu nie będzie zmian to serwisowanie kodu nie będzie potrzebne.