Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

InfoShare 2012 efektywne przeglądy kodu w zespołach agile [Polish]

1,030 views

Published on

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.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

InfoShare 2012 efektywne przeglądy kodu w zespołach agile [Polish]

  1. 1. Efektywne przeglądykodu w zespołach agileWojciech SeligaSpartez Co-founderAtlassian JIRA Development Team Lead Tag cloud generated with Licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. http://www.wordle.net/
  2. 2. Plan to złoPlanowanie to dobro Dlaczego przeglądy kodu Mity Pułapki Efektywność Q&A Picture courtesy of Helico CC BY 2.0
  3. 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. 4. Coprzeglądy kodumają wspólnego z Agile?
  5. 5. Picture courtesy of Cat and Girl CC A-NC-SA 2.5
  6. 6. Wdrażanie nowych ludzi doistniejącego kodu źródłowego styl/konwencje design reużywalne komponenty APIs zasady, praktyki, triki Picture courtesy of mil8 / CC BY 2.0
  7. 7. Mentorowanie junior developerów Bezinwazyjne Asynchroniczne W dogodnej chwili Powodujące mniej frustracji i rozproszania się dla senior developerówPicture courtesy of eddidit / CC BY 2.0
  8. 8. Dzielenie się dobrymipraktykami inżynierskimi
  9. 9. Picture courtesy of Jordan Miller / CC 2.5
  10. 10. Photo Courtesy of U.S. Army
  11. 11. Picture courtesy of tinyfroglet / CC 3.0
  12. 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. 13. Kolejny przeszkadzającyobowiązek więcej spotkań oderwanie się od pracy rozproszenie uwagi
  14. 14. Pożeracz czasudużo kodu do czytania wciąż i wciąż „spanie” na spotkaniachmarnowanie czasu na proste rzeczy:konstrukcje powodujące ostrzeżenia konwencję kodowania nazewnictwo pokrycie testami Picture courtesy of gadl / CC BY-SA 2.0
  15. 15. Ryzyko animozji
  16. 16. Brak konkretnychmierzalnych efektów Picture courtesy of aussiegall / CC BY 2.0
  17. 17. Efektywne przeglądy koduLekkie – prosty i elastyczny procesAsynchroniczneWspierane przez narzędziaRóżnicowe gdzie tylko możliwePrzejrzyste i trwałe, dostępne dla każdegoPrzyjemne dla developerów – proste, szybkie
  18. 18. Prosty Proces Dyskusja: Zakres przeglądu Komentarze, Uwagi, Króciutkie recenzenci Odpowiedzi Podsumowanietermin zakończenia PoprawkiTODO – Kodowanie – Przegląd – QA – DONELimit Kanbanowy jest przydatny
  19. 19. Narzędzia
  20. 20. Proste i szybkie przeglądy Im mniejsze przeglądy tym lepiej Małe częściej lepsze niż duże rzadziej
  21. 21. Rozsądna liczba recenzentów 30 25Czas poświęcony [min] 20 15 10 5 0 1 2 3 4 5 6 Liczba recenzentów
  22. 22. Rozsądna liczba recenzentów 30Liczba 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. 23. Szybkie i przyjemne przeglądy kodudeadline na jutroniewielu recenzentówz komentarzami odautorapost-commit zamiastpre-commit Picture courtesy of Svadilfari / CC BY-ND 2.0
  24. 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 wojnyPicture courtesy of PantoDX / CC BY 2.0
  25. 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. 26. Największe początkowe zagrożeniaSztywny procesMetrykiMicro-managementZbyt duży narzutZespoły jednak ewoluują... Picture courtesy of tms. / CC BY-NC-ND 2.0
  27. 27. Niespodziewane KorzyściZnaczne ułatwienie przyzespołach rozproszonychgeograficznieWspółpraca przyszczegółowym projektowaniuŁatwiejsze do wdrożenianiż pair-programmingRóżnica stref czasowychmoże być korzystnaBaza Wiedzy Picture courtesy of david.nathan.cox / CC BY 2.0
  28. 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. 29. Picture courtesy of Kevin Dooley / CC BY 2
  30. 30. Q&A Picture courtesy of Mykl Roventine / CC BY 2.0
  31. 31. Dziękuję za uwagę Wojciech Seliga Twitter: @wseliga wojciech.seliga@spartez.com

×