Dziś będzie bardziej technicznie, chociaż temat dotyczy zarządzania ryzykiem i budżetem 🙂

Czy manualne Code Review (CR) ma jeszcze sens w dzisiejszych czasach? Jeśli sprawdzanie Pull Requestów (PR) zajmuje zespołowi około 20% czasu sprintu, to czy nie jest to koszt, który powinniśmy zredukować?

Mamy teraz wiele narzędzi, które mogą zweryfikować różne aspekty commitowanego kodu. Mogą odrzucić kod z nieprawidłowymi spacjami zamiast tabów, niewystarczającym pokryciem testami czy brakiem komentarzy. Ale nadal wydaje się, że manualne CR jest koniecznością.

Moim zdaniem, jest to jedna z tych rzeczy, które “zawsze tak robiliśmy” i ciężko się odzwyczaić. Sam obszar programowania w kontekście AI również przechodzi przez te fazy. Bariera wejścia w pregenerowany kod może być duża. Ale dziś nie o tym, wróćmy do CR.

Uważam, że manualne CR jest kosztowne w stosunku do efektu. Gdybyśmy zainwestowali te pieniądze w budowę środowiska CI z automatycznymi testami kodu, jakie jest prawdopodobieństwo, że do repozytorium trafi coś niewłaściwego? Aby tak się stało, developer musiałby napisać kod wystarczająco źle, ale tak, by automat się nie zorientował.

A gdyby dodać do całości warunek, że nowe algorytmy faktycznie mają wymóg manualnych CRek ale potem już wchodzą w automatyczne. To znów pytanie jak duże jest ryzyko, że wydamy coś co nie będzie działać (po testach CI, UATach)?

Mając na przykład 4 backendowców zarabiających po 15K, miesięczny koszt CR to 12K, czyli prawie wynagrodzenie 5 developera…