Code Review - marcinogo/robot GitHub Wiki

1. Poprawne budowanie, jeśli projekt nie buduje się na Jenkinsie nawet nie sprawdzamy projektu

2. Czy projekt buduje się bez błędów i ostrzeżeń

3. Raporty Checkstyle, Sonara, Spotbugs, Jacoco itd. - czy błędy i ostrzeżenia wygenerowane w raporcie można na pewno zignorować

4. Czy jest dokumentacja do publicznych API

5. Czy dokumentacja jest napisana odpowiednio

6. Czy szczegółowo tłumaczy funkcjonalność i działanie klas i metod.

7. Czy dokumentacja zawiera odpowiednie tagi i linki (@link, @author itp.)

Sprawdzamy czystość kodu - wg zasad z Clean Code wujka, czyli:

1. modyfikatory dostępu

2. obecność martwego kodu

3. literówki, poprawny angielski

4. wszelkie code smells

5. Poprawność testów:

6. Czy pokrycie jest odpowiednie

7. Czy testy są dobrze nazwane

8. Czy pisane w konwencji GWT

9. Czy wybrane testy posiadają Data Provider’y

10. Czy rzeczywiście sprawdzają to co powinny

11. Czy testują wszystkie przypadki nie tylko szczęśliwą ścieżkę

Robiąc recenzję należy szczegółowo opisać rzeczy do poprawy oraz, gdy recenzja odrzuca “pull request” podać wszelkie powody dlaczego, tak aby z napisanych komentarzy można było jednoznacznie określić co jest do poprawy.

Recenzja kodu to nie 30 min tylko parę godzin, róbcie je dokładnie i szczegółowo. Fajny artykuł dotyczący dobrych praktyk podczas recenzowania kodu:

Best practices for peer code review

W lokalnym repozytorium odpalamy komendę:

mvn clean verify site

Po budowie projektu sprawdzamy raporty znajdujące się w folderze target/site. Polecam odpalić je w przeglądarce bo mamy proste i przejrzyste GUI. Jeśli projekt ma kilka modułów to dla każdego modułu będą niezależne raporty!

Arkusz do recenzji

Po zrobieniu zadania wystawiamy "pull request" i bierzemy się za recenzowanie innego. Pamiętajcie, każde zadanie musi być zatwierdzone przez co najmniej 2 recenzentów. Śmiało można też prosić wybrane osoby o recenzje, jeśli mają na to czas. Zadanie, które przejdzie recenzje powinno znaleźć się w kolumnie “do scalenia” na tablicy zadań. Potem jest scalane do deva. Jeśli dev zostanie scalony z masterem to zadania lądują w kolumnie “wypchnięte i święte” i można je uznać za zamknięte.