Slideshare.net (beta)

 

All comments

Add a comment on Slide 1

If you have a SlideShare account, login to comment; else you can comment as a guest


Showing 1-50 of 1 (more)

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

From wiktor, 10 months ago

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

4563 views  |  0 comments  |  1 favorite  |  31 downloads  |  4 embeds (Stats)
 

Tags

 

 
 

Groups / Events

 

 
Embed
options

More Info

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License
This slideshow is Public
Total Views: 4563
on Slideshare: 3760
from embeds: 803

Slideshow transcript

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

Slide 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.

Slide 3: moja historia

Slide 4: ZPP

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

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

Slide 8: Co to jest przegląd kodu?

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

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

Slide 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.

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

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

Slide 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ć,

Slide 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,

Slide 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.

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

Slide 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)

Slide 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)

Slide 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)

Slide 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)

Slide 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)

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

Slide 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

Slide 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

Slide 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

Slide 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

Slide 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

Slide 29: Rzeczywistość code-review

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

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

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

Slide 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,

Slide 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ę.

Slide 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

Slide 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

Slide 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

Slide 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

Slide 39: 3 podejścia do code- review

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

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

Slide 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,

Slide 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 :),

Slide 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,

Slide 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,

Slide 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 :(.

Slide 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 :(.

Slide 48: Nieblokujące przeglądy kodu

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

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

Slide 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,

Slide 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,

Slide 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,

Slide 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,

Slide 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.

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

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

Slide 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,

Slide 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.

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

Slide 61: Jak to działa?

Slide 62: Jak to działa? programista

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

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

Slide 65: Inne bajery

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

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

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

Slide 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,

Slide 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ą).

Slide 71: Wizualny diff

Slide 72: Innowacyjna implementacja

Slide 73: Innowacyjna implementacja

Slide 74: Innowacyjna implementacja

Slide 75: Innowacyjna implementacja

Slide 76: Innowacyjna implementacja

Slide 77: Innowacyjna implementacja

Slide 78: Innowacyjna implementacja

Slide 79: Innowacyjna implementacja

Slide 80: Innowacyjna implementacja

Slide 81: Dlaczego warto to zrobić?

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

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

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

Slide 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,

Slide 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.

Slide 87: Proces wytwórczy aplikacji

Slide 88: Proces wytwórczy aplikacji

Slide 89: Proces wytwórczy aplikacji

Slide 90: Proces wytwórczy aplikacji

Slide 91: Proces wytwórczy aplikacji

Slide 92: Proces wytwórczy aplikacji

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

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