Oczywiście w idealnym świecie najlepiej byłoby mieć zarówno Code Review (CR) jak i Pair Programming (PP).
Jednak w brutalnej rzeczywistości zwykle nie ma to czasu, ponieważ ich wykonywanie wiąże się ze złudzeniem tracenia czasu.
Na szczęście w dojrzałych organizacjach znajdujemy czas na tego typu "zbytki" rozumiejąc ich potrzebę - szczególnie w przypadku ekspansji zespołu o "młodych, zdolnych, dobrze zapowiadających się".
Wówczas zwykle defultowo wybór pada na CR.
Co takiego możemy sprawdzić podczas CR?
Na pewno:
- dużą część zasad Clean Code
- poziom sensowności testów
- bardzo ogólnie zgodność z założonym stylem architektonicznym
- przy większym zaangażowaniu być może część reguł GRASP lub SOLID.
<dygresja>
Co do podstawowych zasad Clean Code to wydawać by się mogło, że są intuicyjne. Że każdy podczas pierwszego roku nauki programowania (czy to w podstawówce czy to na studiach) zrozumiał, że krótkie metody i samoopisujące się identyfikatory - GOOD, odwrotnie - BAD.
Okazuje się, że jednak niekoniecznie. W wolnej chwili przyjrzycie się sobie i kolegom z teamu pod kątem dominacji jednego z dwóch typów inteligencji: werbalnej i algorytmicznej.
Polecam Doskonały artykuł Andrzeja Szczodraka: "O programiście-pisarzu i programiście-konstruktorze..."
Dobitnie mówi o tym również Greg Young "gdzieś" w swoim 6.5 godzinnym video.
Ogólny morał jest taki: ważne aby odpowiednio przypisywać programistów o naturalnych zdolnościach do odpowiednich części systemu.
Generalnie różnica polega na tym, że programiści o dominującej inteligencji werbalnej dbają o formę wyrazu. Ich nastawienie - a wręcz predyspozycje - determinują elegancki styl, czytelność i prostotę (prostotę w rozumieniu werbalnym). A Możliwość eleganckiego i prostego wyrażenia intencji jest dla nich narzędziem weryfikacji poprawności pomysłu (weryfikacji nie formalnej ale bardziej intuicyjnej). Algorytmy nie są ich mocną stroną, raczej wzorce, ogólne zasady i formy, architektury, archetypy. Mają niestety chorobliwą tendencję do tworzenia frameworków, aby nadać ramy myślom.
Z kolei programiści o dominującej inteligencji algorytmicznej doskonale czują się w złożonej gmatwaninie obostrzeń nie dbając o styl i formę - te są dla nich pomijalne. Na poziomie algorytmu liczy się wydajność. Ich mocną stroną są raczej biblioteki niż frameworki.
Dodatkowo kilkanaście lat stukania młotkiem w głowę na lekcjach/zajęciach z matematyki gdzie dobra nazwa funkcji to f albo g, dobra nazwa zmiennej to x, y, k, l, m, n a najlepsze zadania to te bez kontekstu i bez treści - umacniają naturalne nawyki.
</dygresja>
Mam nadzieję, że szczypta psychologii rzuci nieco nowego światła na podstawowe zasady Clean Code - z którymi jako entuzjasta dobrych modeli werbalnych osobiście zgadzam się w zupełności. Jednak innych ludzi trzeba również zrozumieć i nie można być zawsze Clean-Nazi.
Poza tym wiele z podstawowych zasad czystego kodu można sprawdzić automatycznie.
Jak jednak sprawdzić design? Jak sprawdzić sensowność koncepcji rozwiązania? Jak sprawdzić model biznesowy?
//Pomijamy tutaj organizacje, gdzie takowe artefakty przychodzą "z góry" do wklepania.
Zakładam też, że sprawdzanie designu metrykami z automatu to jak ocenianie obrazu poprzez histogram;)
Zatem aby sprawdzić tej klasy problemy podczas CR, weryfikujący musi niemal powielić całą pracę umysłową osoby, która weryfikowany kod spłodziła. Czyli innymi słowy mamy podwójny wysiłek mentalny!
Co jeżeli rzeczywiście go poniesiemy (czyli sprawdzimy coś więcej niż nazwy zmiennych i długość metod) i okaże się, że cała koncepcja rozwiązania jest błędna i należało by ją przepisać?
Czy przepisujemy, czy może kończymy CR stwierdzeniem: "następnym razem postaraj się bardziej"?
Skoro już inwestujemy czas drugiej osoby (zwykle tej "mocniejszej") w powstanie kodu, to może warto zrobić to na początku. Tak aby ta osoba brała udział w powstawaniu koncepcji rozwiązania a nie tylko sprawdzała długość metod;)
Jest wówczas duża szansa na:
- wyklucie się lepszego rozwiązania, modelu, koncepcji
- eliminację potrzeby przepisania
- czysty kod będzie niejako produktem ubocznym - ekspert zwykle nie potrafi pisać inaczej niż czysto - syf po prostu go spowalnia lub wręcz uniemożliwia myślenie
Dlatego lepiej zawczasu uprawiać Pair Programming (model kierowcy i pilota) aniżeli poniewczasie liczyć linijki w metodach i sprawdzać czy zmienne nazywają się tak podpowiada zdrowy rozsądek;P
Innymi słowy: mając ograniczone man-hoursy do zainwestowania, lepszy zwrot uzyskamy z PP.
Mam nadzieję, że archaiczne wyrazy użyte w ostatnim akapicie nadały temu postowi poniosły, świąteczny charakter;)
//=======================================
W psychologii uczenia się, mentoring uznaje się za najbardziej efektywną technikę uczenia. Po prostu my, ludzie w ogromnej większości uczymy się przez naśladownictwo - przynajmniej na pierwszych poziomach kompetencji (vide model Dreyfus).
