Jak nauczyć się robić code review?

0

Jak posiąść wiedzę potrzebną, żeby być w stanie robić dobre code review?

Jak można refaktoryzować kod poza jego stylem, lepszą czytelnośćią itp. ? Czyli czy są jakieś techniki by szybciej połapać się co dany kod robi?

5

imo aby robic dobre code review nalezy:

  • zostac opieprzonym pare(set) razy na review wlasnego kodu
  • czytac dobry kod
  • pisac dobry kod
  • robic code review innym (zamierzona rekurencja)
  • byc troche pedantycznym ale zarazem racjonalnym

edit:
oprocz zdrowego rozsadku, znajomosci jezyka, frameworka i standardow kodowania moze sie przydac:
http://www.tutorialspoint.com/design_pattern/
http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672

0

Ech to widzę, że może za kilka lat będę w stanie być lepszy.

Niestety bardzo dawno nikt mi nie robił code review i czuję, że na tym tracę :(

0

Tracisz. Mówię z doświadczenia :)
Nie wyobrażam sobie teraz pracować w miejscu bez code review.

0

Nie to, że nie ma, tylko za malo czasu mamy...

0

Jak macie za mało czasu to coś jest nie tak, np plan projektu. Code review daje bardzo dużo, np:
-Rozwija piszącego kod
-Rozwija robiącego review
-Pomaga utrzymać dobre praktyki w projekcie
-Pomaga utrzymać spójny styl kodowania w projekcie

Jak to tylko jeden taki przypadek, to można przymknąć oko i wyciągnąć wnioski, jak nie to pomyśl o zmianie firmy.

0

Jestem obecnie koniem pociągowym projektu... Mój team lead nie ma czasu, a jest moim guru. I technicznie koleś bardzo mocny. Z kolei inni programisci potrzebują mojej pomocy.

Biznes ciśnie, wrzuca nowe rzeczy bez planu, często słabo zdefiniowane. Architektura microservices, gdzie nowy microservice wrzucamy na spontanie bo biznes chce. Przez to aplikacja staje sie rozproszoną aplikacją monolityczną... QA czasem cos przepusci lub nie przetestuje w ogole.

Naturalnie pojawia się problem jakości...

1
AreQrm napisał(a):

Code review daje bardzo dużo, np:
-Rozwija piszącego kod
-Rozwija robiącego review
-Pomaga utrzymać dobre praktyki w projekcie
-Pomaga utrzymać spójny styl kodowania w projekcie

No to pomyśl. Podejmujesz się jakiegoś tam projektu, masz jakiś termin na jego realizację, klient za to płaci. Pół biedy jeśli np. masz rozliczenie typu Fixed price i klient dokładnie wie ile ma zapłacić i wie kiedy zamierzasz ten projekt skończyć.

Skoro dochodzisz do takich super wniosków że to tyle daje to mi odpowiedz na takie pytania?

  1. Jak dużo czasu potrzebujesz żeby Twój kod był że tak powiem na jakimś przyzwoitym poziomie?
  2. Jak to Twoje Code Review wpłynie na cenę projektu (pamiętaj że nie jesteś sam na rynku, konkurencja nie śpi)
  3. Jak to ma się do ryzyka potencjalnych błędów?

Typowa sytuacja to jest rozliczenie nie Fixed Price ale typowo na godziny. Pod pretekstem CR Ty mógłbyś wciskać klientowi który zresztą się nie zna (bo nie musi), że trzeba przeznaczyć więcej czasu na realizację projektu, on więcej zapłaci w przypadku czegoś takiego oprogramowanie będzie działało i tak tak samo. Gdzie tu jest logika?

Ja tu mówię o takich projektach, gdzie się czegoś podejmujesz i zasadniczo na tym się kończy a nie o perspektywie ich późniejszej rozbudowy. Najlepszym przykładem był tu system do obsługi wyborów, oczywiście wielu wykopowych trolli pojechało dość ostro po tym kodzie ale co by dla przykładu dał CR i refaktoryzacja w przypadku gdyby ten system działał bez szwanku?

Ad 1. Sprawa nie jest wcale taka prosta, bo nawet frameworki jakby się im tak bliżej przyjrzeć to w nowszych wersjach są o niebo lepiej (i rozsądniej) napisane a dopóki nie wyszła nowa wersja to kod był tworzony pod tą która istnieje. Zobacz jakie dla przykładu są różnice w tym co jest w Laravel 4 vs. Laravel 5 albo zestaw sobie jeszcze Laravel z Symfony 2, o ile w ogóle interesujesz się albo programujesz w PHP.

Po każdym kodzie generalnie można by pojechać w zależności od upodobania, więc to chyba nie jest wcale takie proste, że Twoja wersja po refaktoryzacji powinna być najwłaściwsza, bo może tylko Ty tak uważasz. Po jakimś czasie wyjdzie nowsza wersja frameworka w którym coś zmienią albo inny lepszy framework i co wtedy zrobisz? Zaczniesz refaktoryzować bo konwencje w nowszej wersji są lepsze?

5

@drorat1 tylko ze ty mówisz o klepnięciu komuś stronki za miskę ryżu a @AreQrm mówi o pisaniu dużych systemów które piszą dziesiątki koderów jednocześnie, przez wiele lat. Jak musisz UTRZYMYWAĆ taki soft przez wiele lat to nagle okazuje sie że kosz słabego kodu jest znacznie wiekszy niż koszt dobrego kodu, mimo że koszt poniesiony "do pierwszego releasu" może być złudnie niższy.

2

Tutaj parę uwag: http://jezenthomas.com/code-review-done-right/

Ogólnie "code review" to taki sam buzzword jak "agile" czy TDD. Generalnie jest świetną wymówką dla firmy "nasz soft jest cudowny, mamy code review", w praktyce często nic nie wnosi. Review ma sens, jeśli robi je osoba, która poza tym, że świetnie zna język i frameworki, to ogarnia projekt, a poza tym jest uczciwa i skrupulatna. Niestety w praktyce wygląda to często tak: "dobra, to wpisz mnie i chodź na szluga".

0
somekind napisał(a):

Ogólnie "code review" to taki sam buzzword jak "agile" czy TDD. Generalnie jest świetną wymówką dla firmy "nasz soft jest cudowny, mamy code review", w praktyce często nic nie wnosi. Review ma sens, jeśli robi je osoba, która poza tym, że świetnie zna język i frameworki, to ogarnia projekt, a poza tym jest uczciwa i skrupulatna. Niestety w praktyce wygląda to często tak: "dobra, to wpisz mnie i chodź na szluga".

Ja osobiście nie spotkałem się z takim podejściem. W firmach gdzie pracowałem "code review" albo w ogóle nie było, albo było wykonane bardzo rzetelnie. Może po prostu dobrze trafiałem.

Review rzeczywiście nie ma sensu, jeżeli ktoś ocenia kod na "ładne oczy" albo jeżeli w zespole brakuje kompetentnych osób.

1 użytkowników online, w tym zalogowanych: 0, gości: 1