Nie zawsze lubimy to zadanie. Może dlatego, że nie wiemy jak się prawidłowo za nie zabrać?

Dlaczego przeglądy kodu są ważne?

Parafrazując znane zdanie: nie pytaj co tym może zrobić dla code review ale co przegląd kodu może zrobić dla Ciebie ;-)

• Oszczędza czas - ponowne wykorzystanie wiedzy współpracowników.
• Uczy nowych rzeczy - ucz się od swoich współpracowników (i na ich błędach…).
• Pochwal się swoją pracą – jest to także jakaś forma dzielenia się swoją wiedzą z zespołem.

Nie doprowadzaj recenzenta do płaczu

Przeglądy kodu nie są po to, by niszczyć juniorów. Jaki jest sens w poniżaniu juniorów? Recenzja kodu powinna być konstruktywna. Nie popisuj się swoją wiedzą. Pomagaj innym, nie poniżaj ich.

Podczas code review nie zaśmiecaj kodu innych. Negatywne komentarze nie przynoszą nic dobrego. Niczego się z nich nie nauczysz bo nie widzisz w nich poprawek a tylko nabrzmiałe ego. Porozmawiaj z autorem offline bo to nie zawsze akurat umiejętności kodowania są problemem. Przyczyną błędów może być również zła komunikacja, słabe wymagania i niekontrolowany rozrost zakresu prac. Code review robi się razem z autorem kodu a nie przeciwko niemu.

Doceń czas innych

Nie zdążysz na testy. Nie sformatowałeś kodu i jeszcze brakuje Ci komentarza do kodu. To się zdarza każdemu. Większość programistów nie przegląda swojego własnego kodu. Polegają na współpracownikach. Ale to nie oni a Ty jesteś odpowiedzialny za jakość własnego kodu. Jak to ujął Michael Lynch:

Twój kolega z zespołu przychodzi do pracy każdego dnia z ograniczonym zasobem koncentracji. Jeśli przeznaczy część z tego dla Ciebie, to jest to czas, którego nie może poświęcić na własną pracę.

Recenzuj sam siebie. Stylizacja, pisanie komentarzy, to wszystko oszczędzi pracy osobom, które będą przeglądały Twój kod.

Kultura recenzenta

Większość deweloperów używa komentarzy formułowanych przez „ty”. Nie mówią do kodu, który mają przed sobą. Mówią do „Ciebie”, recenzenta. To stawia cię w centrum uwagi, co wywołuje reakcję walki lub ucieczki. W wielu przypadkach jest to niestety reakcja walki. Oceniaj kod, nie osobę.

Jako recenzent podawaj programiście przykłady. Dobrze jest wyciągnąć sobie fragment przeglądanego kodu, debugować go i testować na swoich własnych przykładach. Większość programistów tego nie robi (jasne, często z powodu braku czasu a nie chęci).

Przykład złego komentarza do kodu: Użyj Optionali. Lepiej zakomentuj to tak: Twój kod byłby lepszy gdybyś użył Optionali. Możesz to zrobić na przykład tak: ….

Nie komentuj tylko cudzych pull requestów

Tak, umieszczaj komentarze na diffie – to jest przydatne gdy komunikat dotyczący danego pull requestu nie wystarcza. Dzięki takim komentarzom możesz sprecyzować problem. Ale uwaga: nie komentuj całego diff'u, a jedynie jego newralgiczne punkty.

Kiedy na komentarz będzie jakaś reakcja, napisz, co z tego wynikło. Na przykład: Zgodziliśmy się, że to nie jest potrzebne i przenieśliśmy implementację gdzie indziej. Przy dużej ilości zmian tworzy to dobrą historię zmian.

Działanie jest proste: commit messages + dobre komentarze z pull requestów = świetny changelog.

Współpracuj, nie walcz

Większość recenzentów lub narzekać: „To jest złe”, „Nie powinieneś robić tego w ten sposób. Przerób to rozwiązanie”. Narzekanie tylko pogarsza komunikację, wywołuje napięcie i zwiększa stres.

„Brakuje Ci finala dla tej zmiennej”, „Ten styl kodu nie jest poprawny” – tak się nie robi. Kto powiedział, że recenzent może posługiwać się tylko zdaniami oznajmującymi? Zadawaj pytania, na przykład: „Czy możesz wyjaśnić, dlaczego rozwiązanie X jest lepsze od rozwiązania Y?”

Poza tym tu chodzi o skuteczność. Osobie, której kod recenzujesz nie spodoba się, gdy napiszesz negatywny komentarz. Twój komentarz zostanie niekiedy zignorowany – a bug pozostanie.