Slajdy z mojej prezentacji (30min) podczas gdańskiego infoShare (konferencja w języku polskim). Jeśli chcesz wiedzieć jak skutecznie wdrożyć przeglądy kodu (code review), które rzeczywiście coś pozytywnego wnoszą do zespołu (zamiast frustracji) oraz jakich niebezpieczeńst unikać - ta prezentacja może Ci się przydać. W dużmy stopniu prezentacja pokrywa się z moim wcześniejszymi wystąpieniami na Agile 2009 w Chicago oraz JDD 2009, choć jest trochę nowych materiałów i przemyśleń. Ta prezentacja jest w odróżnieniu od poprzednich w języku polskim.

1. Efektywne przeglądy
kodu w zespołach agile
Wojciech Seliga
Spartez Co-founder
Atlassian JIRA Development Team Lead
Tag cloud generated with
Licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. http://www.wordle.net/

2. Plan to zło
Planowanie to dobro
Dlaczego
przeglądy kodu
Mity
Pułapki
Efektywność
Q&A
Picture courtesy of Helico
CC BY 2.0

3. Uwaga!
Prezentacja zawiera lokowanie :)
Nie jestem obiektywny.
Reprezentuję firmy sprzedające
narzędzie do przeglądu kodu.
Z drugiej strony:
Stosuję przeglądy kodu codziennie ...

4. Co
przeglądy kodu
mają wspólnego
z Agile?

5. Picture courtesy of Cat and Girl
CC A-NC-SA 2.5

6. Wdrażanie nowych ludzi do
istniejącego kodu źródłowego
styl/konwencje
design
reużywalne komponenty
APIs
zasady, praktyki, triki
Picture courtesy of mil8 / CC BY 2.0

7. Mentorowanie junior developerów
Bezinwazyjne
Asynchroniczne
W dogodnej chwili
Powodujące mniej frustracji i
rozproszania się dla senior
developerów
Picture courtesy of eddidit / CC BY 2.0

8. Dzielenie się dobrymi
praktykami inżynierskimi

9. Picture courtesy of Jordan Miller / CC 2.5

10. Photo Courtesy of U.S. Army

11. Picture courtesy of tinyfroglet / CC 3.0

12. Trudne przygotowanie
wybór kodu
zorganizowanie osób
do przeglądu
znalezienie
pasującego terminu
rezerwacja sali
konferencyjnej
przygotowanie
wydruków ...
Picture courtesy of jfdervin / CC BY-SA 2.0

13. Kolejny przeszkadzający
obowiązek
więcej spotkań
oderwanie się od pracy
rozproszenie uwagi

14. Pożeracz czasu
dużo kodu do czytania wciąż i wciąż
„spanie” na spotkaniach
marnowanie czasu na proste rzeczy:
konstrukcje powodujące ostrzeżenia
konwencję kodowania
nazewnictwo
pokrycie testami
Picture courtesy of gadl / CC BY-SA 2.0

15. Ryzyko animozji

16. Brak konkretnych
mierzalnych efektów
Picture courtesy of aussiegall / CC BY 2.0

17. Efektywne przeglądy kodu
Lekkie – prosty i elastyczny proces
Asynchroniczne
Wspierane przez narzędzia
Różnicowe gdzie tylko możliwe
Przejrzyste i trwałe, dostępne dla każdego
Przyjemne dla developerów – proste, szybkie

18. Prosty Proces
Dyskusja:
Zakres przeglądu
Komentarze, Uwagi, Króciutkie
recenzenci
Odpowiedzi Podsumowanie
termin zakończenia
Poprawki
TODO – Kodowanie – Przegląd – QA – DONE
Limit Kanbanowy jest przydatny

19. Narzędzia

20. Proste i szybkie przeglądy
Im mniejsze przeglądy tym lepiej
Małe częściej lepsze niż duże rzadziej

21. Rozsądna liczba recenzentów
30
25
Czas poświęcony [min]
20
15
10
5
0
1 2 3 4 5 6
Liczba recenzentów

22. Rozsądna liczba recenzentów
30
Liczba znalezionych błędów na 1KLOC
25
20
15
10
5
0
1 2 3 4 5 6 7 8 9
Liczba recenzentów

23. Szybkie i przyjemne
przeglądy kodu
deadline na jutro
niewielu recenzentów
z komentarzami od
autora
post-commit zamiast
pre-commit
Picture courtesy of Svadilfari / CC BY-ND 2.0

24. Niektóre zasady zwinnych
przeglądów kodu
każdy może dołączyć i
recenzować kod
każdy może rozszerzać
zakres przeglądu
każdy może dołączać inne
osoby
wszystko jest ogólnie-
dostępne wewnątrz firmy
chodzi o naukę, a nie o
oskarżanie się czy wojny
Picture courtesy of PantoDX / CC BY 2.0

25. Przeglądy kodu w Agile – niezrozumienie
fanatyczne poszukiwanie
błędów
fałszywe przekonanie o
braku błędów w
sprawdzonym kodzie
śledzenie losu każdego
pojedynczego komentarza
czy uwagi do kodu
oczekiwanie twardych
metryk
Picture courtesy of Juria Yoshikawa / CC BY-SA 2.0

26. Największe początkowe
zagrożenia
Sztywny proces
Metryki
Micro-management
Zbyt duży narzut
Zespoły jednak ewoluują...
Picture courtesy of tms. / CC BY-NC-ND 2.0

27. Niespodziewane Korzyści
Znaczne ułatwienie przy
zespołach rozproszonych
geograficznie
Współpraca przy
szczegółowym projektowaniu
Łatwiejsze do wdrożenia
niż pair-programming
Różnica stref czasowych
może być korzystna
Baza Wiedzy Picture courtesy of david.nathan.cox / CC BY 2.0

28. Przeglądy Kodu a Pair Programming
weryfikacja tworzenie
później dzielenie się teraz
”represja” wiedzą ”prewencja”
asynchroniczne wspólna synchroniczny
odpowiedzialność
rozproszone fizycznie razem
lepsza jakość
niższa bariera wyższa bariera
ekstensywne współpraca intensywny
trwała nietrwała

29. Picture courtesy of Kevin Dooley / CC BY 2

30. Q&A
Picture courtesy of Mykl Roventine / CC BY 2.0

31. Dziękuję za uwagę
Wojciech Seliga
Twitter: @wseliga
wojciech.seliga@spartez.com