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).
8 komentarzy:
Clean Code to chyba raczej po angielsku się powinno polecać ;)
No i zasady tam zawarte są trochę szersze.
Co do głównej tezy zgadzam się, 2-3 intensywne tygodnie poświęcone na początku młdym zdolnym zwracają się w pierwszych miesiącach. Z tymi wolniej uczacymi się trzeba zrobić jeszcze kilka iteracji. Czyli, jeżeli CR zwraca za dużo WTF to siedzimy PP ;).
Nie zgodzę się trochę z tym, że zasad CleanCode można nauczyć szybko, podstawowych pewnie tak, ale wiele rzeczy przychodzi z doświadczeniem, przy pracy w innej strukturze zespołu, itp.
Tak, dlatego wszędzie gdzie piszę o CC używam przymiotnika "podstawowych".
Pytanie tylko czym dla kogo są te podstawowe zasady... ale nie to jest sednem posta...
Sedno jest takie, że mając do zainwestowania ograniczone man-hoursy lepszy zwrot będzie z PP.
A co do tłumaczenia książki, to każdy wie jak jest:)
ja nie wiem? raczej pochlebne opinie zewsząd dochodziły, że tłumaczenie jest bardzo dobre...
naprawdę jest ogromna różnica? w czym? tzn co tracę czytając polską wersję zamiast angielskiej?
Szczerze mówiąc to ja też nie wiem jak jest w tym konkretnym przypadku... na półce mam wersję en.
Ale skoro piotrb zaczął temat, to automatycznie założyłem, że "coś znowu musi być skopane";)
Zatem wycofuję się ze swojego sarkazmu i mam nauczkę - jak się nie wie to się nie pisze. Jeżeli obraziłem tłumacza lub wydawcę to przepraszam.
Masz rację pisząc o problemach z robieniem Code Reviews post factum.
Ale mozna przeciez robic Code Reviews samej koncepcji (po prostu osoba implementująca opisuje jak by to zrobiła), a także częściowe Code Reviews - jeszcze w trakcie trwania implementacji.
Myślę, że to minimalizuje negatywne konsekwencje, tak też miałem przyjemność pracować. Niestety, Pair Programming bardzo trudno sprzedać klientowi...
Opracowanie koncepcji wcześniej to śliski temat...
Działają tutaj co najmniej 2 siły:
- pewne problemy da się zaprojektować a pewne problemy są typu "eksperyment" (oczywiście mówimy tu o rozsądnym czasie, bo w nieskończonym da się prawie wszystko)
- programiści to też ludzie i podlegają tym samym prawom statystyki w kontekście psychologicznym: pewne typy osobowości preferują wcześniejszy namysł nad problemem a pewne typy wolą podejście "hands on" i tylko podczas działania są w stanie myśleć.
Tak więc jak zwykle... wszystko zależy od kontekstu:)
Tłumaczenia książki można brać z przymróżeniem oka,dobrze też przejrzeć wersję angielską :)
Clean code tylko po polsku, ale fakt czas tej pozycji wcale nie nadgryza czasem tak drastycznie cały czas warta polecenia
Prześlij komentarz