Jak zarządzać jakością kodu w zleconym projekcie?

Ostatnio przejęliśmy kilka projektów do dalszej realizacji. Na pierwszy rzut oka, projekt działał, wyglądał całkiem ładnie, ale po zobaczeniu kodu, okazało się, że czeka nas o wiele cięższa przeprawa niż to na początku planowaliśmy. Zlecając stworzenie aplikacji (mobilnej, webowej lub jakiejkolwiek innej), większość firm skupia się na efekcie - czy działa, jak wygląda, czy ludziom się podoba, czy wszystko jest tak jak było w planie. Natomiast bardzo rzadko, zwłaszcza w świecie MŚP, jest prowadzona kontrola, czy jakość kodu jest zadowalająca.

Wielokrotnie, przejmując projekty po freelancerach do dalszego rozwoju, trafialiśmy na ten sam problem - na ten moment wszystko jeszcze działa, ale dowolna zmiana jest bardzo problematyczna.

Typowymi problemami są zazwyczaj:

1. Bardzo niechlujny kod - nazewnictwo raz jest polskie, raz angielskie, nazwy nie tłumaczą co jest czym, bo pierwotny wykonawca miał to w głowie, komentarze raz są, raz ich nie ma. Często spotykamy taki dualizm kodu - proste rzeczy są pisane całkiem schludnym kodem, komentarze są wszędzie (nawet gdy wcale nie są potrzebne), a rzeczy trudne pisane byle jak, żeby tylko działało. Często widać, że proste zadania pisał Chat GPT lub inny model językowy, tam kod jest nawet schludny. Ale trudniejsze fragmenty są pisane ręcznie, o wiele bardziej niechlujnie. Brakuje w nich komentarzy, konsekwencji w nazewnictwie, utrzymania jakiejkolwiek spójności z resztą kodu.

2. Brak zachowania jednej architektury - są różne podejścia do pisania aplikacji. My zazwyczaj wybieramy Model View ViewModel, ale czasami inne podejścia są rozsądniejsze. Natomiast jedna rzecz jest najważniejsza - jak już raz coś wybraliśmy, to zostajemy z tym wyborem. Najgorszą mordęgą przy dalszych zmianach jest odkrywanie, że koncepcja pisania oprogramowania dynamicznie zmieniała się wraz z humorem wykonawcy.

3. Rozwiązania “na chwilę”, które okazały się na zawsze - często spotykamy rozwiązanie, które na pierwszy rzut oka mogło być tylko stworzone w celu przetestowania jakiejś koncepcji. Niestety, gdy takie rozwiązanie zostanie, to potem odejście od niego, gdy ten kod jest już masowo używany wcale nie jest takie proste. Jedna nieprzemyślana decyzja na początku mści się dalej. Gdy potem trzeba to naprawić, to zmienianie tego jest o wiele trudniejsze, bardziej czasochłonne i wyraźnie droższe. Zwłaszcza, że dobre rozwiązanie powinno być w koszcie pierwszych prac.

   
   

Te błędy często są do uniknięcia, tylko wymagają odpowiedniego podejścia ze strony klienta. Ogromną różnicę robi najbardziej podstawowa komunikacja i kontrola jakości. Proszenie o omówienie dlaczego coś jest tak zrobione a nie inaczej, albo wspólne przejrzenie kodu bardzo dużo zmienia.

Oczywiście, pojawia się podstawowy problem. Co jeżeli klient nie jest osobą techniczną? Sytuacja jest nieco trudniejsza, ale nie fatalna. To, że nie rozumiemy czym jest architektura MVC a czym MVVM nie zmienia, że możemy się zapytać wykonawcy o różnicę i dlaczego wybrał tę a nie inną. Po pierwsze sami się czegoś dowiemy, a po drugie wykonawca ma wtedy narzuconą presję tłumaczenia dlaczego coś robi tak a nie inaczej.

Ocenienie kodu też jest wykonalne bez specjalistycznej wiedzy. Wystarczy zobaczyć, czy sposób w jaki został napisany jest w miarę spójny “na oko”. Nie musimy mieć pełni wiedzy jak on działa, żeby móc uznać czy w każdym miejscu wygląda w miarę porównywalnie. Nawet jeżeli nic z tego nie rozumiemy, to założenie, że “pańskie oko konia tuczy” tutaj też się sprawdza. Nikt nie będzie chciał sprawdzać, jak bardzo może być niechlujny, jeżeli wie, że ktoś to będzie kontrolował. Natomiast, obecność osoby technicznej po stronie klienta, jest ogromnym komfortem, który wyraźnie usprawnia całość prac.

Normą przy realizowaniu projektów i tak są regularne spotkania, więc dodanie 5 czy 10 minut do nich, żeby omówić decyzje techniczne i zobaczyć jak został napisany świeżo wytworzony kod nie zmieni tak wiele pod względem wysiłku, a może zaoszczędzić dziesiątki tysięcy późniejszych kosztów na poprawki.