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?
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?
imo aby robic dobre code review nalezy:
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
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ę :(
Tracisz. Mówię z doświadczenia :)
Nie wyobrażam sobie teraz pracować w miejscu bez code review.
Nie to, że nie ma, tylko za malo czasu mamy...
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.
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...
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?
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?
@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.
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".
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.