Code review to jeden z tych proces\u00f3w, kt\u00f3re wszyscy uwa\u017caj\u0105 za \u015bwi\u0119to\u015b\u0107. \u201eDobra praktyka\u201d, \u201emust-have w zespole\u201d, \u201epodstawa jako\u015bci\u201d. Ale czy kiedykolwiek zatrzyma\u0142e\u015b si\u0119, \u017ceby policzy\u0107, ile czasu Tw\u00f3j zesp\u00f3\u0142 sp\u0119dza na recenzowaniu kodu, a ile realnie zyskujesz na jako\u015bci?<\/p>\n
Pracuj\u0119 z kilkoma zespo\u0142ami programistycznymi i widz\u0119 pewien wz\u00f3r: w firmach, kt\u00f3re narzekaj\u0105 na tempo developmentu, code review cz\u0119sto jest g\u0142\u00f3wnym winowajc\u0105. Nie chodzi o to, \u017ce recenzje s\u0105 niepotrzebne \u2013 wr\u0119cz przeciwnie. Problem le\u017cy w tym, jak s\u0105 przeprowadzane. Oto 3 ciche sygna\u0142y, \u017ce Tw\u00f3j proces code review zabija produktywno\u015b\u0107.<\/p>\n
Je\u015bli przeci\u0119tny PR (pull request) le\u017cy w kolejce do review 2-3 dni, a sam review trwa kolejne 2 godziny, to masz problem. W praktyce oznacza to, \u017ce deweloper prze\u0142\u0105cza si\u0119 mi\u0119dzy zadaniami, traci kontekst i wraca do poprawiania rzeczy, kt\u00f3re ju\u017c dawno wyparowa\u0142y z pami\u0119ci.<\/p>\n
W jednej z firm z kt\u00f3rymi wsp\u00f3\u0142pracowa\u0142em, zesp\u00f3\u0142 8 os\u00f3b narzeka\u0142 na tempo. Po analizie okaza\u0142o si\u0119, \u017ce \u015bredni czas oczekiwania na review wynosi\u0142 2,5 dnia, a sam review to oko\u0142o 1,5 godziny. Tymczasem samo napisanie kodu dla przeci\u0119tnego PR zajmowa\u0142o 3-4 godziny. Prosty rachunek: deweloperzy sp\u0119dzali 40% czasu na czekaniu i poprawkach, zamiast na tworzeniu nowych funkcji.<\/p>\n
Ustal limit czasowy na review \u2013 np. maksymalnie 4 godziny od momentu wys\u0142ania PR. Je\u015bli recenzent nie zd\u0105\u017cy, PR powinien by\u0107 automatycznie przypisany do innej osoby. Wprowad\u017a te\u017c zasad\u0119, \u017ce review nie mo\u017ce trwa\u0107 d\u0142u\u017cej ni\u017c 30 minut \u2013 je\u015bli wymaga wi\u0119cej, to znaczy, \u017ce PR jest za du\u017cy.<\/p>\n
Widz\u0119 to nagminnie: deweloperzy sp\u0119dzaj\u0105 czas na dyskusji o formatowaniu kodu, nazewnictwie zmiennych czy u\u017cywaniu pojedynczych cudzys\u0142ow\u00f3w zamiast podw\u00f3jnych. Tymczasem istniej\u0105 narz\u0119dzia \u2013 lintery, formatter, automatyczne sprawdzanie typ\u00f3w \u2013 kt\u00f3re robi\u0105 to lepiej, szybciej i bez emocji.<\/p>\n
Zesp\u00f3\u0142 z jednej agencji webowej sp\u0119dza\u0142 \u015brednio 40% czasu review na komentarzach dotycz\u0105cych stylu kodu. Po wdro\u017ceniu Prettier i ESLint z surow\u0105 konfiguracj\u0105, czas ten spad\u0142 do praktycznie zera. Dodatkowo, ka\u017cdy PR przed review przechodzi\u0142 przez automatyczne testy i analiz\u0119 statyczn\u0105 \u2013 recenzenci mogli skupi\u0107 si\u0119 wy\u0142\u0105cznie na logice i architekturze.<\/p>\n
Zainwestuj w narz\u0119dzia CI\/CD, kt\u00f3re wy\u0142apuj\u0105 b\u0142\u0119dy stylistyczne i potencjalne problemy jeszcze zanim kod trafi do recenzenta. Ustal, \u017ce na review trafia tylko logika biznesowa i decyzje architektoniczne \u2013 reszt\u0119 za\u0142atwia maszyna.<\/p>\n
To klasyk: zesp\u00f3\u0142 u\u017cywa code review jako g\u0142\u00f3wnej bariery przed b\u0142\u0119dami produkcyjnymi. Efekt? Recenzenci sp\u0119dzaj\u0105 czas na szukaniu wyj\u0105tk\u00f3w, kt\u00f3re nie s\u0105 obs\u0142u\u017cone, dziwnych warunk\u00f3w brzegowych i przypadk\u00f3w, kt\u00f3re powinny by\u0107 pokryte testami jednostkowymi.<\/p>\n
W startupie z kt\u00f3rym pracowa\u0142em, code review by\u0142o jedyn\u0105 form\u0105 kontroli jako\u015bci \u2013 nie by\u0142o test\u00f3w automatycznych. Ka\u017cdy PR przechodzi\u0142 przez 2-3 recenzent\u00f3w, kt\u00f3rzy wy\u0142apywali b\u0142\u0119dy, ale i tak co drugi release ko\u0144czy\u0142 si\u0119 hotfixem na produkcji. Po wdro\u017ceniu test\u00f3w jednostkowych i integracyjnych liczba b\u0142\u0119d\u00f3w spad\u0142a o 80%, a czas review skr\u00f3ci\u0142 si\u0119 do 15 minut.<\/p>\n
Zacznij traktowa\u0107 code review jako uzupe\u0142nienie, a nie zast\u0119pstwo test\u00f3w. Wymagaj, \u017ceby ka\u017cdy PR mia\u0142 pokrycie testami na poziomie co najmniej 80%. Review powinno sprawdza\u0107, czy testy s\u0105 poprawne, a nie wy\u0142apywa\u0107 rzeczy, kt\u00f3re testy mog\u0142yby znale\u017a\u0107.<\/p>\n
Code review to pot\u0119\u017cne narz\u0119dzie, ale tylko je\u015bli jest u\u017cywane z g\u0142ow\u0105. Je\u015bli Tw\u00f3j zesp\u00f3\u0142 sp\u0119dza na nim wi\u0119cej czasu ni\u017c na pisaniu kodu, targuje si\u0119 o formatowanie albo szuka b\u0142\u0119d\u00f3w, kt\u00f3re powinny by\u0107 wy\u0142apane automatycznie \u2013 to znak, \u017ce proces wymaga zmiany.<\/p>\n
Pami\u0119taj: celem code review nie jest znalezienie wszystkich b\u0142\u0119d\u00f3w, ale dzielenie si\u0119 wiedz\u0105, poprawa architektury i zapewnienie, \u017ce zesp\u00f3\u0142 idzie w dobrym kierunku. Reszt\u0119 zostaw maszynom.<\/p>\n
A jakie s\u0105 Twoje do\u015bwiadczenia z code review? Daj zna\u0107 w komentarzu!<\/p>\n","protected":false},"excerpt":{"rendered":"
Wprowadzenie Code review to jeden z tych proces\u00f3w, kt\u00f3re wszyscy uwa\u017caj\u0105 za \u015bwi\u0119to\u015b\u0107. \u201eDobra praktyka\u201d, \u201emust-have w zespole\u201d, \u201epodstawa jako\u015bci\u201d. Ale czy kiedykolwiek zatrzyma\u0142e\u015b si\u0119, \u017ceby policzy\u0107, ile czasu Tw\u00f3j zesp\u00f3\u0142 sp\u0119dza na recenzowaniu kodu, a ile realnie zyskujesz na jako\u015bci? Pracuj\u0119 z kilkoma zespo\u0142ami programistycznymi i widz\u0119 pewien wz\u00f3r: w firmach, kt\u00f3re narzekaj\u0105 na<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[965,497,1010,9],"class_list":["post-2615","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-blokery-produktywnosci","tag-code-review","tag-deweloperzy","tag-jurskitech"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2615","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=2615"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2615\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2615"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2615"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2615"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}