Code Review

Howto's

Filozofia

  • Usprawnianie ogólnej jakości codebase
  • Ograniczenie bugów
  • Dzielenie się wiedzą

Czym nie jest CR

  • Przechwałki
  • Podważanie kompetencji innych
  • Czepianie się

CR to dyskusja

Dyskusja jest obustronna

Pytania nie mają na celu challengowania

"why did you do it" - to nie oznacza że źle, 

tylko ktoś chce zrozumieć czemu

CR to nauka

- Onboarding

- Wymiana doświadczeń

Emocje

- Należy unikać osobistych komentarzy

- Nie należy brać do siebie komentarzy (personalnie)

- Komentarze dotyczą faktów

Dobry PR

WIP PR

- Zabezpieczenie przed utratą kodu

- Track progress

- Wczesne obserwacje podjętych założeń

Opis PR

  • Link do Jiry
  • Opis i kontekst
  • Labelki

Rozmiar PR

  • Im mniejszy PR tym lepiej
  • Wczuj się z reviewera

squash vs merge

  • feature do master - merge
  • lokalne commity na feature branchu - squash

CR Process

Czas

  • Ustalić kiedy robimy CR

Dobry komentarz

  • Rzeczowy i konkretny
  • Opis dlaczego lub pytanie
  • Link do źródła / dokumentacji

Stages

Nitpicks

- Nie czepiamy się

- Oznaczamy które komentarze są ważne

- Definiujemy severity komentarzy *

Zarządzeni dużym PR

- Barrel branch

- Live review

Standaryzacja

- Decyzje z CR jako konfig linta

Standaryzacja

- Decyzje z CR jako konfig linta

1 problem na raz

- Komentarze jako threads

- 1 problem = 1 komentarz

Ownership

- PR ma swojego ownera w czasie

- Należy pracować nad komunikacją, zespół musi mieć jasne na kim "leży" PR

Automatyzacja

- W miarę możliwości automatyzujemy

- Czekamy na przejśćie CI zanim zawołamy do CR

- Testy, hooki, lintery - dopiero potem człowiek

Konflikty

- Zawołanie 3ciej osoby

Q&A

Code Review

By lkostrowski

Code Review

  • 85
Loading comments...

More from lkostrowski