Audyt jakości kodu - zakres i wynik pracy

Audyt jakości kodu to ocena kodu źródłowego, architektury i procesu wytwarzania pod kątem jednego pytania: ile będzie kosztowało utrzymanie i rozwijanie tego systemu przez kolejne dwa lata. Wszystko inne - metryki, narzędzia, listy znalezisk - jest tylko drogą do tej odpowiedzi.

Audyt to nie jest wydruk z SonarQube ani lista ostrzeżeń z lintera. Takie raporty generuje się w kwadrans i nie mówią nic o ryzyku biznesowym: system z tysiącem ostrzeżeń stylistycznych może być zupełnie bezpieczny, a system z zerem ostrzeżeń może trzymać hasła w repozytorium i nie mieć żadnej kopii zapasowej.

To także nie jest ocena programistów. Zły kod bierze się najczęściej z presji terminów, zmieniających się wymagań i braku kogoś, kto pilnuje architektury - a nie z tego, że ktoś nie umie programować. Raport, który kończy się wnioskiem „zespół jest słaby”, jest bezużyteczny, bo nie da się na jego podstawie podjąć żadnej decyzji.

Audyt zwraca się wtedy, gdy przed Tobą stoi konkretna decyzja i brakuje Ci danych, żeby ją podjąć. Najczęstsze sytuacje:

• Rozwój zwolnił i nikt nie potrafi powiedzieć dlaczego - zmiany, które kiedyś zajmowały dzień, dziś zajmują tydzień.
• Przejmujesz projekt po innym wykonawcy i chcesz wiedzieć, co kupujesz, zanim podpiszesz umowę.
• Rozważasz inwestycję w spółkę i potrzebujesz technicznego due diligence.
• Zespół mówi, że trzeba wszystko przepisać, a Ty nie wiesz, czy to konieczność, czy ambicja.
• Zbliża się skokowy wzrost ruchu albo wejście na nowy rynek i nie wiesz, czy system to udźwignie.
• Chcesz ocenić pracę software house’u przed przedłużeniem współpracy na kolejny rok.

Jeśli decyzja i tak jest już podjęta, audyt niczego nie zmieni - będzie tylko drogim potwierdzeniem. Podobnie, jeśli szukasz argumentu do zwolnienia dostawcy albo do wygrania wewnętrznej dyskusji: niezależny audytor nie jest narzędziem w sporze i dobry raport prawie nigdy nie brzmi tak, jak zamawiający chciałby usłyszeć.

Nie ma też sensu audytować projektu, który ma dwa miesiące i trzy tysiące linii kodu. Na tym etapie taniej jest przeczytać kod samemu albo poprosić o jednorazowe code review niż zamawiać pełną ocenę.

Każdy z tych obszarów potrafi samodzielnie zatrzymać rozwój produktu, dlatego żadnego nie da się pominąć bez wyraźnej decyzji zamawiającego.

• Kod źródłowy - czytelność, spójność konwencji, duplikacja, złożoność najczęściej zmienianych plików, obsługa błędów. Nie interesuje mnie kod „ładny”, tylko kod, który da się bezpiecznie zmienić.
• Architektura - granice modułów, kierunek zależności, miejsca, w których jedna zmiana wymusza dziesięć innych. To zwykle tutaj siedzi prawdziwy powód, dla którego rozwój zwolnił.
• Testy - nie sam procent pokrycia, tylko czy testy w ogóle chronią przed regresją i czy zespół im ufa. Zestaw testów, który wszyscy ignorują, jest gorszy niż jego brak, bo kosztuje czas i daje fałszywe poczucie bezpieczeństwa.
• Bezpieczeństwo - sekrety w repozytorium, uprawnienia, aktualność zależności, podatności w bibliotekach, obsługa danych osobowych. Tu znaleziska są zwykle najbardziej pilne i najtańsze do naprawienia.
• Wdrożenia i infrastruktura - czy da się wdrożyć bez ręcznych kroków, czy da się cofnąć wdrożenie, czy istnieją kopie zapasowe i czy ktokolwiek próbował je odtworzyć.
• Proces i wiedza - dokumentacja, historia repozytorium, rozproszenie wiedzy. Systemy, które rozumie tylko jedna osoba, są ryzykiem biznesowym niezależnie od jakości kodu.

Raport ma jedną cechę, która decyduje o jego wartości: da się go przeczytać bez znajomości kodu. Piszę go tak, żeby zarząd albo inwestor rozumiał ryzyko, a zespół techniczny wiedział, co dokładnie zrobić.

Każde znalezisko dostaje trzy rzeczy: opis stanu faktycznego z odniesieniem do konkretnego miejsca w kodzie, konsekwencję biznesową (co się stanie, jeśli tego nie ruszymy) i rekomendację z szacowanym nakładem. Bez tej trzeciej części raport zamienia się w listę pretensji.

Znaleziska są uszeregowane według ryzyka i wpływu, a nie według obszaru. Na górze trafia to, co może wywrócić firmę w tym kwartale, a nie to, co najbardziej drażni programistę. Na końcu jest plan na 30, 90 i 180 dni, bo pierwsze pytanie po lekturze raportu zawsze brzmi „od czego zacząć”.

Raport zamykam rozmową. Dokument, który trafia do szuflady, nie zmienia niczego - decyzje zapadają w rozmowie, w której można dopytać.

Audyt pojedynczego obszaru - na przykład samego bezpieczeństwa albo samego procesu wdrożeń - to zwykle kilka dni. Pełna ocena średniego systemu produkcyjnego to około dwóch tygodni. Więcej rzadko ma sens: po dwóch tygodniach zaczynam znajdować warianty tych samych problemów, a nie nowe.

Koszt zależy od zakresu i wielkości systemu, a nie od liczby linii kodu. Zakres i cenę ustalam przed startem, na podstawie krótkiej rozmowy i zerknięcia do repozytorium - nie wyceniam audytu bez zobaczenia, co audytuję.

Punkt odniesienia: audyt kosztuje ułamek tego, co kosztuje kwartał pracy zespołu w złym kierunku. Jeśli raport zmieni kolejność prac choćby o jeden duży temat, zwraca się natychmiast.

Kilka pytań, na które odpowiedź powinieneś znać bez pomocy z zewnątrz. Jeśli na którekolwiek nie potrafisz odpowiedzieć, masz już wynik wstępnej diagnozy:

• Czy repozytorium należy do Twojej firmy i czy masz do niego dostęp administracyjny?
• Ile czasu zajmuje wdrożenie zmiany na produkcję i ile osób musi przy tym asystować?
• Kiedy ostatnio ktoś odtworzył kopię zapasową, żeby sprawdzić, czy działa?
• Czy jest jakakolwiek zmiana, której zespół boi się dotknąć? Jeśli tak - dlaczego?
• Co się stanie, jeśli jutro zniknie najważniejsza osoba w projekcie?