Temat: Code review - wasze opinie

Witajcie

Piszę posta o code review na blogu Codebraga ( http://codebrag.com/ ) i zbieram wypowiedzi kilku osób do zacytowania na temat korzyści/obaw z robienia code review (przeglądów kodu).

Jakbyś moglibyście rozwinąć poniższą wypowiedź tak do 2-4 zdań to byłbym niezmiernie wdzięczny! :)

Gdybyśmy w projekcie nie robili code review to ….

Ewentualnie jeśli nie robicie code review to pytanie alternatywne:
Nie robimy code review ponieważ...

Z góry dziękuję za pomoc! :)

Temat: Code review - wasze opinie

Tomasz D.:
Gdybyśmy w projekcie nie robili code review to ….

To prędzej czy później i tak będziemy musieli go zrobić, tylko zdecydowanie wyższym kosztem.

Temat: Code review - wasze opinie

Tomasz D.:
Witajcie

Piszę posta o code review na blogu Codebraga ( http://codebrag.com/ ) i zbieram wypowiedzi kilku osób do zacytowania na temat korzyści/obaw z robienia code review (przeglądów kodu).

Jakbyś moglibyście rozwinąć poniższą wypowiedź tak do 2-4 zdań to byłbym niezmiernie wdzięczny! :)

Kto robi to "code review" ?

Temat: Code review - wasze opinie

Gdybyśmy w projekcie nie robili code review to ….

to trzeba by każdego nauczyć pisać dobry kod ....

Temat: Code review - wasze opinie

Jarosław Ż.:

Gdybyśmy w projekcie nie robili code review to ….

to trzeba by każdego nauczyć pisać dobry kod ....

A znasz lepszy sposób uczenia pisania dobrego kodu niż code review? Zwróć też uwagę na fakt, że większość problemów ma kilka tej samej klasy rozwiązań. zarządzanie kodem w którym każdy zachowuje się z danym problemem inaczej to masakra. W szczególności w zakresie ryzyk związanych z migracją pracowników, czy rozwojem zespołu.
Zwróć tez uwagę na fakt, że jakość kodu trzeba jakoś zweryfikować - statyczna i dynamiczna analiza kodu przez automat nie zawsze daje reprezentatywne oceny. Dla mnie code review is a must - szczególnie w pierwszych miesiącach pracy developera w teamie ale i potem pomaga podciągać poziom w górę.

Temat: Code review - wasze opinie

Mateusz K.:

Jarosław Ż.:

Gdybyśmy w projekcie nie robili code review to ….

to trzeba by każdego nauczyć pisać dobry kod ....

A znasz lepszy sposób uczenia pisania dobrego kodu niż code review?

tak, szkolenie, coaching, itp. :), no chyba, że źle zrozumiałem pytanie, bo jeżeli jest to "code review" w trakcie projektu to podtrzymuję swoje zdanie ;)

Zwróć też uwagę na fakt, że większość problemów ma kilka tej samej klasy rozwiązań. zarządzanie kodem w którym każdy zachowuje się z danym problemem inaczej to masakra. W szczególności w zakresie ryzyk związanych z migracją pracowników, czy rozwojem zespołu.

to prawda, ale...
- zadaniem programisty jest realizacja udokumentowanego interfejsu i tu kontrolą jakości jest test
- jeżeli dana klasa (komponent) jest kosztowna w późniejszym utrzymaniu to znaczy, że jej twórca coś źle robi
- migracja pracowników jest kłopotem, ale zachowując zasadę, migracja na danym stanowisku to kolejni ludzie o porównywalnych umiejętnościach (i mamy ustalona jakąś forme dokumentowania) to nie ma tragedii
- prawdą jest, że może być wiele rozwiązań tego samego zadania, ale jeżeli do przemieszczenia się z punktu w punkt angażuję taksówkarza to albo mu powierzam te robotę, celem jest miejsce docelowe i nie dyskutuję z nim którą drogę wybrał, albo mu dokładnie mówię którędy ma jechać, taksówkarza raczej rozliczam nie z tego którędy jedzie a z tego czy dojechałem i w jakim czasie (i jakim kosztem)

Zwróć tez uwagę na fakt, że jakość kodu trzeba jakoś zweryfikować - statyczna i dynamiczna analiza kodu przez automat nie zawsze daje reprezentatywne oceny. Dla mnie code review is a must - szczególnie w pierwszych miesiącach pracy developera w teamie ale i potem pomaga podciągać poziom w górę.

ja oceniam jakość kodu (ale ja reprezentuję zamawiającego) poprzez ocenę koszty cyklu życia (wprowadzanie zmian, rozszerzenia itp.), nie ryzykuje, bo żądam w umowie deklaracji kosztów utrzymania.

Temat: Code review - wasze opinie

Jarosław Ż.:

A znasz lepszy sposób uczenia pisania dobrego kodu niż code review?

tak, szkolenie, coaching, itp. :), no chyba, że źle zrozumiałem pytanie, bo jeżeli jest to "code review" w trakcie projektu to podtrzymuję swoje zdanie ;)

Szkolenie, coaching bez code-review dają bardzo niewiele.

Zwróć też uwagę na fakt, że większość problemów ma kilka tej samej klasy rozwiązań. zarządzanie kodem w którym każdy zachowuje się z danym problemem inaczej to masakra. W szczególności w zakresie ryzyk związanych z migracją pracowników, czy rozwojem zespołu.

to prawda, ale...
- zadaniem programisty jest realizacja udokumentowanego interfejsu i tu kontrolą jakości jest test

Test zweryfikuje jedynie czy funkcjonalność jest spełniana. Można spełniać funkcjonalność pisząc fatalny kod. Ty jako zlecający oprogramowanie jesteś pewnie zainteresowany wyłącznie końcową funkcjonalnością. Ja jako wytwarzający oprogramowanie jestem zainteresowany kodem źródłowym w kwestiach jego maintenance znacznie szerzej. Twoje zainteresowanie w zasadzie kończy się na Open/Close Principle. Moje jest znacząco szersze. Obejmuje code-reuse, łatwość analizy przez innego programistę i wiele innych.

- jeżeli dana klasa (komponent) jest kosztowna w późniejszym utrzymaniu to znaczy, że jej twórca coś źle robi
- migracja pracowników jest kłopotem, ale zachowując zasadę, migracja na danym stanowisku to kolejni ludzie o porównywalnych umiejętnościach (i mamy ustalona jakąś forme dokumentowania) to nie ma tragedii
- prawdą jest, że może być wiele rozwiązań tego samego zadania, ale jeżeli do przemieszczenia się z punktu w punkt angażuję taksówkarza to albo mu powierzam te robotę, celem jest miejsce docelowe i nie dyskutuję z nim którą drogę wybrał, albo mu dokładnie mówię którędy ma jechać, taksówkarza raczej rozliczam nie z tego którędy jedzie a z tego czy dojechałem i w jakim czasie (i jakim kosztem)

Programowanie jest nieco bardziej skomplikowaną sprawą niż jazda taksówką. Twoje obserwacje są teoretycznie poprawne. Praktyka pokazuje jednak, że regularne code-review sprawiają, że programiści znacznie szybciej tworzą znacznie lepszy kod. Programista po roku pracy u mnie uczy się więcej niż po 3 latach w banku.

Zwróć tez uwagę na fakt, że jakość kodu trzeba jakoś zweryfikować - statyczna i dynamiczna analiza kodu przez automat nie zawsze daje reprezentatywne oceny. Dla mnie code review is a must - szczególnie w pierwszych miesiącach pracy developera w teamie ale i potem pomaga podciągać poziom w górę.

ja oceniam jakość kodu (ale ja reprezentuję zamawiającego) poprzez ocenę koszty cyklu życia (wprowadzanie zmian, rozszerzenia itp.), nie ryzykuje, bo żądam w umowie deklaracji kosztów utrzymania.

Ciebie jako klienta warsztatu samochodowego interesuje ile kosztuje przegląd. Mnie jako właściciela warsztatu interesuje:
- ile czasu poświęcił serwisant
- jak długo korzystał z podnośnika
- ile zużył prądu
- jak często trzeba mu uzupełniać skrzynkę narzędziową
- ile razy musi obserwować przegląd nieznanego mu modelu samochodu wykonany przez kolegę zanim sam będzie potrafił go zrealizować
- jak często po jego przeglądzie zdarzają się usterki, które mógł przewidzieć
- czy w wyniku jego dokumentacji przeglądu nowy pracownik nauczy się szybciej robić przeglądy
i wiele, wiele innych;
To, że Tobie code-review jest nie potrzebne to nie znaczy, że to zbędne narzędzie. Masz pewną ograniczoną perspektywę ze względu na rolę w procesie wytwarzania jaką odgrywasz.
Code-review to świetne narzędzie - po prostu nie dla Ciebie.Ten post został edytowany przez Autora dnia 22.01.14 o godzinie 14:30

Temat: Code review - wasze opinie

Przychylam sie do opinii Mateusza, aczkolwiek szkolenia i CR sluza IMHO do czego innego.

Szkolenie to zdobywanie nowej wiedzy, a CR to utrwalanie starej wiedzy i wyrownywanie skilla w zespole oraz dodatkowe oczy przeciw glupocie w kodzie. Dobrze sie wspieraja, ale tez jedno bez drugiego potrafi zyc.

Temat: Code review - wasze opinie

Mateusz K.:
Szkolenie, coaching bez code-review dają bardzo niewiele.

ja rozumiem "przeglądanie kodu" jako przeglądanie kodu wraz z uwaga co do tego co tam jest.... nie da sie "nieprzegladać kodu" podcza coachingu, warsztatów itp...

- zadaniem programisty jest realizacja udokumentowanego interfejsu i tu kontrolą jakości jest test

Test zweryfikuje jedynie czy funkcjonalność jest spełniana.

masz racje dlatego napisałem jak to można ocenić ;)

Można spełniać funkcjonalność pisząc fatalny kod. Ty jako zlecający oprogramowanie jesteś pewnie zainteresowany wyłącznie końcową funkcjonalnością.

oraz kosztami utrzymani i rozwoju :)

Programowanie jest nieco bardziej skomplikowaną sprawą niż jazda taksówką. Twoje obserwacje są teoretycznie poprawne. Praktyka pokazuje jednak, że regularne code-review sprawiają, że programiści znacznie szybciej tworzą znacznie lepszy kod.

traktuje to jako element kontroli jakości :)

Programista po roku pracy u mnie uczy się więcej niż po 3 latach w banku.

wierze Ci :)

To, że Tobie code-review jest nie potrzebne to nie znaczy, że to zbędne narzędzie. Masz pewną ograniczoną perspektywę ze względu na rolę w procesie wytwarzania jaką odgrywasz.
Code-review to świetne narzędzie - po prostu nie dla Ciebie.

zgadzam się z Tobą ale tu mamy chyba nieporozumienie polegające na tym, ze
- czy code review to zarządzanie projektem i uczenie ludzi
- czy code review to element kontroli jakości (podobnie jak ktoś po mnie czyta, poprawia listerówki ki i stylistykę)

Temat: Code review - wasze opinie

Jarosław Ż.:

Mateusz K.:
Szkolenie, coaching bez code-review dają bardzo niewiele.

ja rozumiem "przeglądanie kodu" jako przeglądanie kodu wraz z uwaga co do tego co tam jest.... nie da sie "nieprzegladać kodu" podcza coachingu, warsztatów itp...

traktuje to jako element kontroli jakości :)

To, że Tobie code-review jest nie potrzebne to nie znaczy, że to zbędne narzędzie. Masz pewną ograniczoną perspektywę ze względu na rolę w procesie wytwarzania jaką odgrywasz.
Code-review to świetne narzędzie - po prostu nie dla Ciebie.

zgadzam się z Tobą ale tu mamy chyba nieporozumienie polegające na tym, ze
- czy code review to zarządzanie projektem i uczenie ludzi
- czy code review to element kontroli jakości (podobnie jak ktoś po mnie czyta, poprawia listerówki ki i stylistykę)

Jedno i drugie. Mam wrażenie, że nie do końca wiesz co to jest code review. Opiszę prosty case.
Środowisko: Software house, realizujący dedykowane projekty w iteracyjno-przyrostowym modelu, z wykorzystaniem MDD.
Story:
Osoba odpowiedzialna za implementację use-case (np. Team Leader, lub SeniorDeveloper) wyznacza aktywności jakie są niezbędne aby UC został zrealizowany (np. implementacja backendu, implementacja frontendu, realizacja testów). Spływają mu zrealizowane zadania, kod jest kompilowany, wersja systemu z zaimplementowanym UC publikowana na serwerze developerskim. Robione są testy i hotfixy, ostatecznie stoi wersja, która idzie na testing. Sytuacja się powtarza mamy już zrobione kilka UC, część przeszła testy w zespole, część na testingu, część u klienta, część ma już deploy produkcyjny - normalna sytuacja pod tytułem środek projektu.
Mamy pewną hierarchię developerów w danym obszarze. Np. TL <- SD <- JD. Przy odbieraniu aktywności, odbierający (zwykle bardziej doświadczony lub przynajmniej na tym samym poziomie) przegląda kod źródłowy, który powstał w celu zaimplementowania jakiegoś pakietu funkcjonalności (to może być jedynie część UC). Weryfikuje różne sprawy (zależnie od skilla autora kodu, ryzyk związanych z daną funkcjonalnościa i wielu różnych innych czynników):
- złożoność obliczeniową metod
- styl kodowania
- nazewnictwo
- trzymanie się SOLID/GRASP
- jakość testów jednostkowych
i w zależności od tego jakie rzeczy znajdzie:
- chwali developera (Great Job you have improved much - publicznie czy prywatnie to juz bardziej dyskuja z zakresu zarządzania)
- wybiera fragment, który jest szczególnie dobrze napisany i na następnym szkoleniu/coachingu wewnętrznym będzie on omawiany jako good practice; być może trafia do knowdlege-base jako wewnątrzfirmowy ekwiwalent wzorca projektowego
- wskazuje błędy, które w zależności od tego na ile są poważne albo skutkują natychmiastową koniecznością refaktoringu (czyli zmiany implementacji, przy zachowaniu funkcjonalności), albo wpadają na listę zmian do wprowadzenia "w wolnym czasie" - czyli np. wtedy gdy developer czeka na inne zadania aby kontynuować swoje prace
- szczególnie hardcorowe błędy lub takie, które są powtarzane często przez róznych developerów trafiają na listę do omówienia na szkoleniu wewnętrznym/coachingu jako bad practice
Efekty stosowania code-review są bardzo pozytywne i dotyczą wielu obszarów:
- jakości tworzonego produktu
- rozwoju osobistego developerów
- rozowju jakości świadczonych usług przez firmę jako całość
- obniżenia kosztów utrzymania i rozwoju oraz tworzenia nowych aplikacji
Code-review to nie jest code-reading żeby zabic czas na kibelku. W terminologii zarządzania projektami jest to technika wspierania tzw. lessons learned.

Temat: Code review - wasze opinie

OK, rozumiem, że to po protu jakaś uporządkowana praca w grupie i wewnętrzne samokształcenie i wymiana wiedzy połączane z zarządzaniem jakością.

ja niestety do tej pory spotykałem się z raczej wersją "zatrudniliśmy ad-hoc programistów do konkretnego i nie znamy ich więc ktoś musi ich pilnować"...

czyli na początku źle zrozumiałem :)

Temat: Code review - wasze opinie

Jarosław Ż.:

zgadzam się z Tobą ale tu mamy chyba nieporozumienie polegające na tym, ze
- czy code review to zarządzanie projektem i uczenie ludzi
- czy code review to element kontroli jakości (podobnie jak ktoś po mnie czyta, poprawia listerówki ki i stylistykę)

a dlaczego niby są to wykluczające się rzeczy?

Temat: Code review - wasze opinie

Jarosław Ż.:
OK, rozumiem, że to po protu jakaś uporządkowana praca w grupie i wewnętrzne samokształcenie i wymiana wiedzy połączane z zarządzaniem jakością.

ja niestety do tej pory spotykałem się z raczej wersją "zatrudniliśmy ad-hoc programistów do konkretnego i nie znamy ich więc ktoś musi ich pilnować"...

czyli na początku źle zrozumiałem :)

To bym nazwał masochizmem lub skrajną niekompetencją a nie code-review:P

Temat: Code review - wasze opinie

Jarosław S.:

Jarosław Ż.:
zgadzam się z Tobą ale tu mamy chyba nieporozumienie polegające na tym, ze
- czy code review to zarządzanie projektem i uczenie ludzi
- czy code review to element kontroli jakości (podobnie jak ktoś po mnie czyta, poprawia listerówki ki i stylistykę)

a dlaczego niby są to wykluczające się rzeczy?

bo w moim subiektywnym odczuciu realizacja projektu dla klienta nie powinna być szkółką na kliencie, w każdym razie ja nie chciał bym być takim klientem...

Temat: Code review - wasze opinie

Tomasz D.:
Gdybyśmy w projekcie nie robili code review to ….

- stracilibyśmy jedną z okazji do wzajemnego doskonalenia się
- negatywnie wpłynęlibyśmy na rozumienie kodu/komponentów przez deweloperów
- odbiłoby się to na jakości produktu

Poza tym, zrozumienie kodu w trakcie, gdy on powstaje (tym bardziej, gdy code review są małe i wrzucane systematycznie) nie sprawia większego problemu. Jeżeli jednak pominelibyśmy jego robienie, to w przyszłości brak wiedzy, którą zyskalibyśmy poprzez jego robienie (nawet biorąc pod uwagę, że jest ona po pewnym czasie mglista), odbije się na czasie, który poświęcimy na czytanie i zrozumienie kodu. Oczywiście ten czas zależy również w dużej mierze od jakości tego kodu, ale przy skomplikowanych/starych/etc. komponentach mimo wszystko trzeba na to poświęcić trochę czasu.

Dodatkowo code review moim zdaniem uczy pokory - co jakiś czas dostajesz dowody na to, że czasami rozwiązania, z których jesteś naprawdę dumny, nie są najlepszymi z możliwych, a niekiedy zawierają błędy.

Temat: Code review - wasze opinie

True, nic nie poprawia jakosc kodu, jak naprawde dobry developer, ktory sprawdza Twoj kod z zawzietoscia starego faszysty... bedziesz ciezko pracowal, aby nie popelniac bledow ponownie (uczyl sie wiec), co po jakims czasie wchodzi w krew.

Temat: Code review - wasze opinie

Sebastian M.:
odbije się na czasie, który poświęcimy na czytanie i zrozumienie kodu.

Wystarczy mieć na bieżąco prowadzony koncepcyjny (jego aktualizacja jest wtedy relatywnie rzadka) diagram komponentów i klas, niejedna książka dla developerów zawiera magiczną dobrą praktykę: zanim napisze kilkaset linii kodu narysuj go sobie i upewnij się czy to dobry pomysł. bez tego, odtworzenie sobie "w głowie" takiej struktury wymaga wielu godzin spędzonych na "code review".... jeżeli taki jest tego cel...

Temat: Code review - wasze opinie

Jarosław Ż.:
Wystarczy mieć na bieżąco prowadzony koncepcyjny [...] diagram komponentów i klas

Jedno nie wyklucza drugiego i takie rzeczy też (poza code review) u mnie w zespole mamy. Z tym, że takie diagramy pomagają zrozumieć idee, koncept, mechanizm.
Są jednak dwa "ale". Po pierwsze, niekiedy same metody są złożone i nawet jeżeli są dobrze napisane to spojrzenie na nie w trakcie powstawania (gdy dany problem wszyscy mają jeszcze w głowach) naprawdę sporo daje.
Po drugie, nie widzę potrzeby nanoszenia każdej najdrobniejszej klasy na taki diagram, ponieważ stanie się on nazbyt skomplikowany co negatywnie wpłynie na jego czytelność. Jeżeli idea się nie zmienia, ale w trakcie kodowania klasa została rozbita (ze względu na czytelność i przyszłe zarządzanie kodem) na pomniejsze elementy, ale nadal ich (klas) zbiór powinien być traktowany jako całość, to też tym zostanie na diagramie.
Brak tych detali na diagamie nie wpłynie negatywnie na zrozumienie mechanizmu, zaś ich umieszczenie mogłoby go niepotrzebnie skomplikować.

bez tego, odtworzenie sobie "w głowie" takiej struktury wymaga wielu godzin spędzonych na "code review".... jeżeli taki jest tego cel...

Code review nie służy do przypominania sobie czegoś. Od tego są dokumentacje, diagramy oraz jakość i czytelność kodu, która w tym pomaga.
Ta aktywność ma na celu propagację wiedzy, zarówno tej dotyczącej bezpośrednio projektu (sposobu implementacji funkcjonalności) jak i stosowanych rozwiązań, sposobów myślenia, itp. Gdy jednak mówimy o code review mamy na myśli dzielenie się wiedzą na temat rzeczy, nad którymi aktualnie pracujemy.

Napisałeś wcześniej:

realizacja projektu dla klienta nie powinna być szkółką na kliencie

i oczywiście zgadzam się z Tobą. Jednak code review to nie aktywność, którą można przyrównać do np. szkolenia. Dla mnie jest to raczej coś na wzór czytania specjalistycznych blogów. Żeby tam zajrzeć i ze zrozumieniem zgłębiać treści muszę posiadać pewną wiedzę. Czasami przeczytam o czymś nowym, co wywoła "efekt aha", czasami ugruntuję wiedzę, a czasami się nie zgodzę. Nie każdy artykuł zawiera coś, czego nie wiedziałem, ale śledzenie ich pozwala mi być "na bieżąco", nie starcić niczego istotnego.

Temat: Code review - wasze opinie

Piotr J.:
True, nic nie poprawia jakosc kodu, jak naprawde dobry developer, ktory sprawdza Twoj kod z zawzietoscia starego faszysty...

Tylko nie można też popadać w skrajności, bo może zacząć się tworzenie "sztuki dla sztuki" :)
Z tą jakością jest moim zdaniem tak samo jak z refaktoryzacją - w pewnym momencie trzeba sobie powiedzieć dość i, tak jak powiedział kiedyś mój kolega, trzeba zadawać właściwe pytania/dawać odpowiednie komentarze, bo na pytanie czy może być lepiej chyba zawsze padnie ta sama odpowiedź :)

Temat: Code review - wasze opinie

Jarosław Ż.:

Sebastian M.:
odbije się na czasie, który poświęcimy na czytanie i zrozumienie kodu.

Wystarczy mieć na bieżąco prowadzony koncepcyjny (jego aktualizacja jest wtedy relatywnie rzadka) diagram komponentów i klas, niejedna książka dla developerów zawiera magiczną dobrą praktykę: zanim napisze kilkaset linii kodu narysuj go sobie i upewnij się czy to dobry pomysł. bez tego, odtworzenie sobie "w głowie" takiej struktury wymaga wielu godzin spędzonych na "code review".... jeżeli taki jest tego cel...

Kłania się Twoja własna przypowieść o młotku... Nie wszystkie problemy świata rozwiążesz projektując rozwiązanie:)