Gdy wpiszemy frazę Code Review w wyszukiwarce Google, otrzymamy ponad 2,5 mln rezultatów. Część z tych wyników to artykuły wyjaśniające pojęcie, niektóre wskazują dobre praktyki, a jeszcze inne opisują jak można usprawnić proces Code Review. Często proponowane są check listy, ograniczenia czasowe na przeprowadzanie przeglądu kodu czy też wspomaganie się różnymi narzędziami np. do Static Code Analyse.
Wszystko co robimy, tworząc oprogramowanie powinno posiadać swój cel. Gdy mówimy o przeglądach kodu definiujemy cele tego procesu jako m.in: wymiana wiedzy, zapobieganie silosom wiedzy, standaryzacja powstającego kodu, detekcja uchybień oraz błędów.
Skupię się na tym ostatnim z wymienionych. Należy zaznaczyć, że nie jest to efekt uboczny procesu Code Review, a wręcz przeciwnie – to jeden z jego najważniejszych elementów, który moim zdaniem, powinien posiadać wysoki priorytet. Warto więc zadbać aby cel ten, był realizowany z jak największą skutecznością. Ważna jest „JAKOŚĆ” (na każdym etapie tworzenia oprogramowania), a nie realizacja na poziomie „JAKOŚ„.
Jak w takim razie podnieść tę efektywność? Biorąc pod uwagę:
- ogólnodostępne źródła wiedzy – artykuły, książki (szczególnie polecam artykuł Jasona Cohena),
- własne doświadczenie z przeglądami kodu.
Można dojść do mniej więcej następującego wniosku:
Ilość wykrytych defektów wzrasta wraz ze spadkiem ilości zmian do przejrzenia.
Czyli podsumowując – wrogiem w osiąganiu najwyższej skuteczności ww. celu jest duża ilość zmian w obrębie jednego Code Review.
Jak poradzić sobie z dużą ilością zmian na Code Review? Najzwyczajniej w świecie dostarczać mniej zmian dla jednego przeglądu kodu. Wiąże się to z dekompozycją zadania na mniejsze części (np. w sposób formalny poprzez kolejne zadania w Issue Tracker), ale także ze zmianą strategii dostarczania zmian – etapami, inkrementacyjnie. Mniej, a częściej.
Jeśli Twoje przeglądy kodu to:
- niekończąca się lista zmian,
- kilkanaście lub więcej commitów,
- kilkadziesiąt zmienionych plików.
Spróbuj się zatrzymać, zweryfikować i usprawnić bolączkę projektową. Code Review ma przynosić wartość programistom oraz projektowi. Niech nie będzie procesem, którego nienawidzisz.
Jeśli chcesz pogłębić temat usprawniania przeglądów kodu, to polecam zapoznać się z poniższymi artykułami:
- 11 proven practices for more effective, efficient peer code review
- Effective Code Reviews – 9 Tips from a Converted Skeptic
- Code Reviews: Just Do It
- Best Kept Secrets of Peer Code Review – SmartBear (PDF)
Świetna obserwacja, nigdy nie zwróciłem uwagi na tę prostą zależność, a faktycznie od kiedy pamiętam tak to tak w praktyce wygląda 😉
Jedna linijka zmian – coś się znajdzie do poprawy. Tydzień kodowania – approved without suggestions 😉