Code Review, czyli przegląd kodu - prezentacja tematu pracy magisterskiej

1. Code-review, czyli
przegląd kodu
Wiktor Gworek
V rok informatyki MIMUW
http://blog.mocna-kawa.com

2. Tłumaczenie code-review
• Nie ma dobrego
odpowiednika code-review w
języku polskim,
• możliwe tłumaczenia to
dozór kodu, przegląd kodu,
• code-review jest znane także
jako peer-review.

3. moja historia

4. ZPP

5. Zespołowy Projekt
Programistyczny
My konia kuliśmy, a żaby nam nogi podstawiały.

7. Różne
potworki:
• giveName() zamiast getName(),
• nie pozamykane pliki,
• czasem nikt nie wiedział, co
aplikacja ma robić.

8. Co to jest przegląd kodu?

9. Co to jest przegląd kodu?
• Jeden programista piszę kod, a
drugi jest proszony o jego
przegląd,

10. Co to jest przegląd kodu?
• Jeden programista piszę kod, a
drugi jest proszony o jego
przegląd,
• “delikatna” krytyka linijka po
linijce,

11. Co to jest przegląd kodu?
• Jeden programista piszę kod, a
drugi jest proszony o jego
przegląd,
• “delikatna” krytyka linijka po
linijce,
• celem jest kooperacja, a nie usilne
szukanie błędów.

12. Po co code-review jeśli
robię testy jednostkowe?

13. Po co code-review jeśli
robię testy jednostkowe?
• Obie rzeczy są po to, aby minimalizować
liczbę błędów,

14. Po co code-review jeśli
robię testy jednostkowe?
• Obie rzeczy są po to, aby minimalizować
liczbę błędów,
• nie wszystko da się prztestować,

15. Po co code-review jeśli
robię testy jednostkowe?
• Obie rzeczy są po to, aby minimalizować
liczbę błędów,
• nie wszystko da się prztestować,
• architektura, zaprojektowanie aplikacji,

16. Po co code-review jeśli
robię testy jednostkowe?
• Obie rzeczy są po to, aby minimalizować
liczbę błędów,
• nie wszystko da się prztestować,
• architektura, zaprojektowanie aplikacji,
• wszyscy w zespole znają lepiej kod aplikacji.

17. Zalety code-review (1)
uchowanie przed
godzinami debuggowania
senior developer - junior
developer (czarna praca)

18. Zalety code-review (1)
• Dwie pary oczu znajdują więcej błędów niż
jedna,
uchowanie przed
godzinami debuggowania
senior developer - junior
developer (czarna praca)

19. Zalety code-review (1)
• Dwie pary oczu znajdują więcej błędów niż
jedna,
• znajdowane błędów we wstępnych cyklach pisania aplikacji,
uchowanie przed
godzinami debuggowania
senior developer - junior
developer (czarna praca)

20. Zalety code-review (1)
• Dwie pary oczu znajdują więcej błędów niż
jedna,
• znajdowane błędów we wstępnych cyklach pisania aplikacji,
• zwiększenie pewności, że stworzony kod jest
lepiej zaprojektowany,
uchowanie przed
godzinami debuggowania
senior developer - junior
developer (czarna praca)

21. Zalety code-review (1)
• Dwie pary oczu znajdują więcej błędów niż
jedna,
• znajdowane błędów we wstępnych cyklach pisania aplikacji,
• zwiększenie pewności, że stworzony kod jest
lepiej zaprojektowany,
• utrzymanie czytelności i wysokiej jakości kodu, uchowanie przed
godzinami debuggowania
senior developer - junior
developer (czarna praca)

22. Zalety code-review (1)
• Dwie pary oczu znajdują więcej błędów niż
jedna,
• znajdowane błędów we wstępnych cyklach pisania aplikacji,
• zwiększenie pewności, że stworzony kod jest
lepiej zaprojektowany,
• utrzymanie czytelności i wysokiej jakości kodu,
• zachęca programistów do wzajemnej
uchowanie przed
godzinami debuggowania
senior developer - junior
komunikacji. developer (czarna praca)

23. Zalety code-review (2)
subtelne i niepisane
zasady
wiedza o tym, kto jest w
czym dobry, a gdzie
trzeba się jeszcze komus
przygladac

24. Zalety code-review (2)
• Nauczanie świeżych programistów,
subtelne i niepisane
zasady
wiedza o tym, kto jest w
czym dobry, a gdzie
trzeba się jeszcze komus
przygladac

25. Zalety code-review (2)
• Nauczanie świeżych programistów,
• dzielenie się wiedzą i doświadczeniem,
subtelne i niepisane
zasady
wiedza o tym, kto jest w
czym dobry, a gdzie
trzeba się jeszcze komus
przygladac

26. Zalety code-review (2)
• Nauczanie świeżych programistów,
• dzielenie się wiedzą i doświadczeniem,
• uczenie się z błędów bez psucia niczego,
subtelne i niepisane
zasady
wiedza o tym, kto jest w
czym dobry, a gdzie
trzeba się jeszcze komus
przygladac

27. Zalety code-review (2)
• Nauczanie świeżych programistów,
• dzielenie się wiedzą i doświadczeniem,
• uczenie się z błędów bez psucia niczego,
• stworzenie zaufania,
subtelne i niepisane
zasady
wiedza o tym, kto jest w
czym dobry, a gdzie
trzeba się jeszcze komus
przygladac

28. Zalety code-review (2)
• Nauczanie świeżych programistów,
• dzielenie się wiedzą i doświadczeniem,
• uczenie się z błędów bez psucia niczego,
• stworzenie zaufania,
• alternatywa dla kodowania w parach. subtelne i niepisane
zasady
wiedza o tym, kto jest w
czym dobry, a gdzie
trzeba się jeszcze komus
przygladac

29. Rzeczywistość code-review

30. Rzeczywistość code-review
• Trudny do wprowadzenia,

31. Rzeczywistość code-review
• Trudny do wprowadzenia,
• większość programistów nie lubi
krytyki,

32. Rzeczywistość code-review
• Trudny do wprowadzenia,
• większość programistów nie lubi
krytyki,
• korzyści nie są zauważalne od
razu,

33. Rzeczywistość code-review
• Trudny do wprowadzenia,
• większość programistów nie lubi
krytyki,
• korzyści nie są zauważalne od
razu,
• publiczne przeglądy kodu zabierają
za dużo czasu,

34. Rzeczywistość code-review
• Trudny do wprowadzenia,
• większość programistów nie lubi
krytyki,
• korzyści nie są zauważalne od
razu,
• publiczne przeglądy kodu zabierają
za dużo czasu,
• niezależne przeglądy kodu
duplikują pracę.

35. Fakty o code-review
Kiedy ser wlet otrzymuje
więcej niż 20 requestów
na sekundę to pojawia
się deadlock pomiędzy
A.java:128 a B.java:56

36. Fakty o code-review
• Przeglądy kodu nie ujawniają krytycznych
błędów,
Kiedy ser wlet otrzymuje
więcej niż 20 requestów
na sekundę to pojawia
się deadlock pomiędzy
A.java:128 a B.java:56

37. Fakty o code-review
• Przeglądy kodu nie ujawniają krytycznych
błędów,
• programiści stają się bardziej uczciwi,
Kiedy ser wlet otrzymuje
więcej niż 20 requestów
na sekundę to pojawia
się deadlock pomiędzy
A.java:128 a B.java:56

38. Fakty o code-review
• Przeglądy kodu nie ujawniają krytycznych
błędów,
• programiści stają się bardziej uczciwi,
• trzeba spędzić więcej czasu, żeby
uczynić kod bardziej czytelnym.
Kiedy ser wlet otrzymuje
więcej niż 20 requestów
na sekundę to pojawia
się deadlock pomiędzy
A.java:128 a B.java:56

39. 3 podejścia do code-
review

40. 3 podejścia do code-
review
• Brak przeglądu kodu,

41. 3 podejścia do code-
review
• Brak przeglądu kodu,
• nieblokujące przeglądy kodu,

42. 3 podejścia do code-
review
• Brak przeglądu kodu,
• nieblokujące przeglądy kodu,
• sprawdzenie następuje zazwyczaj po wprowadzeniu kodu do
repozytorium,

43. 3 podejścia do code-
review
• Brak przeglądu kodu,
• nieblokujące przeglądy kodu,
• sprawdzenie następuje zazwyczaj po wprowadzeniu kodu do
repozytorium,
• takie właśnie lubimy :),

44. 3 podejścia do code-
review
• Brak przeglądu kodu,
• nieblokujące przeglądy kodu,
• sprawdzenie następuje zazwyczaj po wprowadzeniu kodu do
repozytorium,
• takie właśnie lubimy :),
• blokujące przeglądy kodu,

45. 3 podejścia do code-
review
• Brak przeglądu kodu,
• nieblokujące przeglądy kodu,
• sprawdzenie następuje zazwyczaj po wprowadzeniu kodu do
repozytorium,
• takie właśnie lubimy :),
• blokujące przeglądy kodu,
• nic nie jest wprowadzanie do repozytorium dopóki nie jest
sprawdzone,

46. 3 podejścia do code-
review
• Brak przeglądu kodu,
• nieblokujące przeglądy kodu,
• sprawdzenie następuje zazwyczaj po wprowadzeniu kodu do
repozytorium,
• takie właśnie lubimy :),
• blokujące przeglądy kodu,
• nic nie jest wprowadzanie do repozytorium dopóki nie jest
sprawdzone,
• takich nie lubimy :(.

47. 3 podejścia do code-
review
• Brak przeglądu kodu,ogóle nie lubimy
tego w
• nieblokujące przeglądy kodu,
• sprawdzenie następuje zazwyczaj po wprowadzeniu kodu do
repozytorium,
• takie właśnie lubimy :),
• blokujące przeglądy kodu,
• nic nie jest wprowadzanie do repozytorium dopóki nie jest
sprawdzone,
• takich nie lubimy :(.

48. Nieblokujące przeglądy
kodu

49. Nieblokujące przeglądy
kodu
• Brak blokady repozytorium,

50. Nieblokujące przeglądy
kodu
• Brak blokady repozytorium,
• nie trzeba siedzieć i czekać na przegląd,

51. Nieblokujące przeglądy
kodu
• Brak blokady repozytorium,
• nie trzeba siedzieć i czekać na przegląd,
• programista dokonuje przeglądu wtedy, kiedy ma
na to czas,

52. Nieblokujące przeglądy
kodu
• Brak blokady repozytorium,
• nie trzeba siedzieć i czekać na przegląd,
• programista dokonuje przeglądu wtedy, kiedy ma
na to czas,
• wejdzie mu to w nawyk tak, jak pisanie testów,

53. Nieblokujące przeglądy
kodu
• Brak blokady repozytorium,
• nie trzeba siedzieć i czekać na przegląd,
• programista dokonuje przeglądu wtedy, kiedy ma
na to czas,
• wejdzie mu to w nawyk tak, jak pisanie testów,
• 10 sekund poświęcone pisaniu komentarza
ułatwia znacząco jego czytanie,

54. Nieblokujące przeglądy
kodu
• Brak blokady repozytorium,
• nie trzeba siedzieć i czekać na przegląd,
• programista dokonuje przeglądu wtedy, kiedy ma
na to czas,
• wejdzie mu to w nawyk tak, jak pisanie testów,
• 10 sekund poświęcone pisaniu komentarza
ułatwia znacząco jego czytanie,
• zdrowy nawyk, ćwiczenie umysłowe,

55. Nieblokujące przeglądy
kodu
• Brak blokady repozytorium,
• nie trzeba siedzieć i czekać na przegląd,
• programista dokonuje przeglądu wtedy, kiedy ma
na to czas,
• wejdzie mu to w nawyk tak, jak pisanie testów,
• 10 sekund poświęcone pisaniu komentarza
ułatwia znacząco jego czytanie,
• zdrowy nawyk, ćwiczenie umysłowe,
• poznawanie innych stylów/idiomów kodowania.

56. Prostsza forma code-
review Pomysł na współdzielone
pliki, workspace’y
działające w czasie
rzeczywistym.

57. Prostsza forma code-
review Pomysł na współdzielone
pliki, workspace’y
działające w czasie
rzeczywistym.
• Wirutalne przeglądy kodu,

58. Prostsza forma code-
review Pomysł na współdzielone
pliki, workspace’y
działające w czasie
rzeczywistym.
• Wirutalne przeglądy kodu,
• wiadomości przesyłane pomiędzy
programistami są zorientowane na kod,

59. Prostsza forma code-
review Pomysł na współdzielone
pliki, workspace’y
działające w czasie
rzeczywistym.
• Wirutalne przeglądy kodu,
• wiadomości przesyłane pomiędzy
programistami są zorientowane na kod,
• wprowadzenie komunikacji dające poczucie
jakby inni programiści byli obok siebie.

60. O czym jest ta
magisterka?
Jest to system wspomagający dokonywanie wirtualnych
przeglądów kodu.

61. Jak to działa?

62. Jak to działa?
programista

63. Jak to działa?
programista repozytorium
(subversion)

64. Jak to działa?
programista repozytorium nighthawk
(subversion) code-review

65. Inne bajery

66. Inne bajery
• Ładne kolorowanie składni i diff’ów,

67. Inne bajery
• Ładne kolorowanie składni i diff’ów,
• przeglądanie wizualne kodu w
repozytorium (!),

68. Inne bajery
• Ładne kolorowanie składni i diff’ów,
• przeglądanie wizualne kodu w
repozytorium (!),
• workflow: draft > approval > review >
summarize > closed,

69. Inne bajery
• Ładne kolorowanie składni i diff’ów,
• przeglądanie wizualne kodu w
repozytorium (!),
• workflow: draft > approval > review >
summarize > closed,
• role: author, reviewer, moderator,

70. Inne bajery
• Ładne kolorowanie składni i diff’ów,
• przeglądanie wizualne kodu w
repozytorium (!),
• workflow: draft > approval > review >
summarize > closed,
• role: author, reviewer, moderator,
• integracja z FindBugs (z analizą statyczną).

71. Wizualny diff

72. Innowacyjna
implementacja

73. Innowacyjna
implementacja

74. Innowacyjna
implementacja

75. Innowacyjna
implementacja

76. Innowacyjna
implementacja

77. Innowacyjna
implementacja

78. Innowacyjna
implementacja

79. Innowacyjna
implementacja

80. Innowacyjna
implementacja

81. Dlaczego warto to
zrobić?

82. Dlaczego warto to
zrobić?
• Nieoceniony dla rozproszonych zespołów
programistycznych,

83. Dlaczego warto to
zrobić?
• Nieoceniony dla rozproszonych zespołów
programistycznych,
• przeglądy online zamiast czytania gazeta.pl,

84. Dlaczego warto to
zrobić?
• Nieoceniony dla rozproszonych zespołów
programistycznych,
• przeglądy online zamiast czytania gazeta.pl,
• szybkie przygotowanie kodu do przeglądu,

85. Dlaczego warto to
zrobić?
• Nieoceniony dla rozproszonych zespołów
programistycznych,
• przeglądy online zamiast czytania gazeta.pl,
• szybkie przygotowanie kodu do przeglądu,
• komentowanie inline,

86. Dlaczego warto to
zrobić?
• Nieoceniony dla rozproszonych zespołów
programistycznych,
• przeglądy online zamiast czytania gazeta.pl,
• szybkie przygotowanie kodu do przeglądu,
• komentowanie inline,
• metryka, możliwość odpowiedzi.

87. Proces wytwórczy
aplikacji

88. Proces wytwórczy
aplikacji

89. Proces wytwórczy
aplikacji

90. Proces wytwórczy
aplikacji

91. Proces wytwórczy
aplikacji

92. Proces wytwórczy
aplikacji

93. Harmonogram
do końca listopada:
zebranie wymagań i opracowanie
koncepcji
do końca pierwszego semestru:
implementacja
do końca kwietnia:
papierkowa robota

94. Pytania?
Wiktor Gworek
http://blog.mocna-kawa.com