Cel nadrzędny
Nadrzędnym celem jest ta sama lub wyższa jakość kodu – nie chcemy na pewno aby kod stracił na jakości.
Co sprawdzamy?
1. Czytelność kodu
2. Względy bezpieczeństwa
3. Pokrycie testami
4. Czy kod jest zgodny z architekturą aplikacji
5. Czy wykorzystywane są re-używalne komponenty
Pytania które warto sobie zadać
1. Czy rozumiem co robi kod?
2. Czy kod spełnia wymagania opisane w zadaniu?
Czego unikać?
1. Wyśmiewania/chamstwa i innych tego typu rzeczy
2. Sprawdzania kodu, który zawiera ponad 400 linii kodu – są badania pokazujące, że im więcej kodu jest do sprawdzenia, tym mniej znajdujemy istotnych rzeczy
Przegląd kodu jako element nauki
Warto też pamiętać, że robienie code review to świetny sposób na rozwój – można podpatrzeć ciekawe rozwiązania lub też wspólnie wypracować coś ciekawego.
Statyczna analiza
Statyczna analiza kodu jest świetnym wsparciem, ale nie zastąpi tutaj człowieka (na przykład w takich aspektach jak czystość kodu czy też weryfikacja założeń).
Nitpick – czyli mało istotne rzeczy
Czasami się zdarza, że mamy drobną uwagę co do kodu, ale nie jest to coś co by miało blokować ten kod przed „mergowaniem”. W takich sytuacjach popularnym rozwiązaniem jest zastosowanie prefiksu „Nit: ” – co oznacza, że to jest raczej czepianie się niż bardzo istotna rzecz:
Nit: You can add a new line hereWarto zajrzeć
- Google code review guidelines https://google.github.io/eng-practices/review/
- Chromium code review guidelines https://chromium.googlesource.com/chromium/src/+/main/docs/contributing.md#Code-review
- Studium przypadku w Cisco https://static1.smartbear.co/support/media/resources/cc/book/code-review-cisco-case-study.pdf