Code review to jeden z tych proces\u00f3w, kt\u00f3re wszyscy znaj\u0105, ale niewielu wdra\u017ca dobrze. Widz\u0119 to regularnie \u2013 nawet w firmach, kt\u00f3re maj\u0105 bud\u017cet na narz\u0119dzia i kadr\u0119 in\u017cyniersk\u0105. Zamiast zdrowej wymiany opinii, code review staje si\u0119 formalno\u015bci\u0105: \u201eLGTM\u201d na czacie, mergowanie bez komentarzy, albo przeciwnie \u2013 tygodnie oczekiwania na feedback. W obu przypadkach Tw\u00f3j zesp\u00f3\u0142 traci czas, a produkt nabywa d\u0142ug techniczny. W tym artykule poka\u017c\u0119 3 najcz\u0119stsze b\u0142\u0119dy w code review i jak je realnie naprawi\u0107.<\/p>\n
Najcz\u0119\u015bciej spotykam si\u0119 z przekonaniem, \u017ce code review to etap po<\/em> sko\u0144czeniu funkcji. \u201eNapiszemy, a potem kto\u015b to sprawdzi\u201d. Problem w tym, \u017ce takie podej\u015bcie zamienia review w audyt \u2013 programista czeka dni, feedback przychodzi hurtem, a poprawki s\u0105 kosztowne, bo kod ju\u017c osadzony w kontek\u015bcie.<\/p>\n Przyk\u0142ad:<\/strong> W jednej z firm, z kt\u00f3r\u0105 wsp\u00f3\u0142pracowa\u0142em, zesp\u00f3\u0142 czeka\u0142 \u015brednio 3 dni na review. W tym czasie programista zaczyna\u0142 kolejne zadanie, a potem musia\u0142 wraca\u0107 do poprzedniego. Efekt? Cz\u0119\u015b\u0107 poprawek nigdy nie by\u0142a wdra\u017cana, bo kontekst ucieka\u0142.<\/p>\n Rozwi\u0105zanie:<\/strong> <\/p>\n Drugi cz\u0119sty grzech to brak standard\u00f3w. Ka\u017cdy recenzuje wed\u0142ug w\u0142asnego uznania \u2013 jedni zwracaj\u0105 uwag\u0119 tylko na styl, inni na wydajno\u015b\u0107, a jeszcze inni nie zwracaj\u0105 uwagi na nic. Skutek? Jako\u015b\u0107 kodu jest nier\u00f3wna, a nowi programi\u015bci nie wiedz\u0105, czego si\u0119 trzyma\u0107.<\/p>\n Przyk\u0142ad:<\/strong> W startupie, kt\u00f3ry audytowa\u0142em, code review ogranicza\u0142o si\u0119 do sprawdzenia, czy kod si\u0119 kompiluje i czy testy przechodz\u0105. Nikt nie patrzy\u0142 na architektur\u0119 ani na to, czy kod jest nadmiarowy. Po p\u00f3\u0142 roku mieli taki ba\u0142agan, \u017ce ka\u017cda zmiana wymaga\u0142a refaktora.<\/p>\n Rozwi\u0105zanie:<\/strong><\/p>\n Code review to najbardziej polityczna aktywno\u015b\u0107 w zespole. Niby m\u00f3wimy \u201eto tylko kod\u201d, ale emocje s\u0105 realne. Je\u015bli recenzent u\u017cywa sformu\u0142owa\u0144 \u201eto jest \u017ale\u201d, \u201enie rozumiem, dlaczego tak zrobi\u0142e\u015b\u201d, autor zaczyna si\u0119 broni\u0107, a nie s\u0142ucha\u0107. Powstaje napi\u0119cie, kt\u00f3re hamuje rozw\u00f3j.<\/p>\n Przyk\u0142ad:<\/strong> W jednej firmie senior developer regularnie komentowa\u0142 PR m\u0142odszych z ironi\u0105. Po trzech miesi\u0105cach dw\u00f3ch programist\u00f3w odesz\u0142o, a reszta ba\u0142a si\u0119 wysy\u0142a\u0107 PR-y bez konsultacji. Code review sta\u0142o si\u0119 buteleczk\u0105 w\u0105skiego gard\u0142a.<\/p>\n Rozwi\u0105zanie:<\/strong><\/p>\n Code review to nie formalno\u015b\u0107 \u2013 to narz\u0119dzie do podnoszenia jako\u015bci, dzielenia si\u0119 wiedz\u0105 i budowania kultury in\u017cynierskiej. Je\u015bli Tw\u00f3j zesp\u00f3\u0142 skacze na g\u0142\u0119bok\u0105 wod\u0119 bez procesu albo traktuje review jako przeszkod\u0119, zmie\u0144 podej\u015bcie. Ma\u0142e PR-y, jasne kryteria i szacunek dla autora \u2013 to trzy filary, kt\u00f3re realnie oszcz\u0119dzaj\u0105 czas i pieni\u0105dze. U mnie w JurskiTech.pl wdro\u017cyli\u015bmy te zasady i widzimy efekty: szybciej wypuszczamy funkcje, mniej bug\u00f3w, lepsza atmosfera. Spr\u00f3buj, a zobaczysz r\u00f3\u017cnic\u0119.<\/p>\n","protected":false},"excerpt":{"rendered":" Wprowadzenie Code review to jeden z tych proces\u00f3w, kt\u00f3re wszyscy znaj\u0105, ale niewielu wdra\u017ca dobrze. Widz\u0119 to regularnie \u2013 nawet w firmach, kt\u00f3re maj\u0105 bud\u017cet na narz\u0119dzia i kadr\u0119 in\u017cyniersk\u0105. Zamiast zdrowej wymiany opinii, code review staje si\u0119 formalno\u015bci\u0105: \u201eLGTM\u201d na czacie, mergowanie bez komentarzy, albo przeciwnie \u2013 tygodnie oczekiwania na feedback. W obu przypadkach<\/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,113,1071],"class_list":["post-2787","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-blokery-produktywnosci","tag-code-review","tag-jakosc-kodu","tag-zespol-developerski"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2787","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=2787"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2787\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2787"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2787"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2787"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
B\u0142\u0105d 2: Brak kryteri\u00f3w oceny \u2013 \u201eto dzia\u0142a, to mergujemy\u201d<\/h2>\n
\n
B\u0142\u0105d 3: Ocenianie ludzi, a nie kodu<\/h2>\n
\n
Podsumowanie<\/h2>\n