Pami\u0119tam projekt sprzed kilku lat \u2013 platforma e-commerce dla \u015bredniej wielko\u015bci sklepu z odzie\u017c\u0105. Zesp\u00f3\u0142 6 developer\u00f3w, sprinty dwutygodniowe, a mimo to ka\u017cdy feature wchodzi\u0142 na produkcj\u0119 z op\u00f3\u017anieniem. Kiedy usiedli\u015bmy do analizy, okaza\u0142o si\u0119, \u017ce nie chodzi\u0142o o pisanie kodu \u2013 to sz\u0142o ca\u0142kiem sprawnie. Prawdziwym w\u0105skim gard\u0142em by\u0142y code review. Pull requesty czeka\u0142y na akceptacj\u0119 \u015brednio 3 dni. Seniorzy, kt\u00f3rzy mieli je sprawdza\u0107, byli zasypani w\u0142asnymi zadaniami. Efekt? Zesp\u00f3\u0142 tworzy\u0142 pod pr\u00f3g uwagi, a b\u0142\u0119dy i tak przechodzi\u0142y na produkcj\u0119, bo nikt nie mia\u0142 czasu ich wy\u0142apa\u0107.<\/p>\n
To nie jest odosobniony przypadek. Znam dziesi\u0105tki firm, kt\u00f3re w ten spos\u00f3b trac\u0105 czas, pieni\u0105dze i nerwy. A przecie\u017c code review to jeden z filar\u00f3w jako\u015bci w software developmentzie. Tylko \u017ce wi\u0119kszo\u015b\u0107 zespo\u0142\u00f3w robi to po prostu \u017ale \u2013 albo przez chaos procesowy, albo przez brak narz\u0119dzi, albo przez kultur\u0119, w kt\u00f3rej przegl\u0105d kodu jest traktowany jak przykry obowi\u0105zek.<\/p>\n
W tym artykule poka\u017c\u0119 Ci, jakie b\u0142\u0119dy najcz\u0119\u015bciej pope\u0142niamy w code review i jak je naprawi\u0107, \u017ceby zesp\u00f3\u0142 dzia\u0142a\u0142 szybciej, a jako\u015b\u0107 kodu nie ucierpia\u0142a. Bo uwierz mi \u2013 da si\u0119 pogodzi\u0107 tempo wdro\u017ce\u0144 z porz\u0105dnymi review.<\/p>\n
Najcz\u0119stszy problem, jaki widz\u0119 w firmach, to traktowanie code review jak formalno\u015bci, kt\u00f3r\u0105 trzeba odhaczy\u0107. Seniorzy maj\u0105 swoje zadania, a przegl\u0105d cudzego kodu spychaj\u0105 na wiecz\u00f3r albo weekend. W efekcie pull request czeka kilka dni, a tymczasem zesp\u00f3\u0142 idzie dalej \u2013 powstaj\u0105 konflikty w ga\u0142\u0119ziach, trzeba je rozwi\u0105zywa\u0107, a wiedza o tym, co w\u0142a\u015bciwie si\u0119 zmieni\u0142o, ulatuje.<\/p>\n
Pami\u0119tam cz\u0142onka zespo\u0142u, kt\u00f3ry narzeka\u0142, \u017ce nie mo\u017ce skupi\u0107 si\u0119 na swojej pracy, bo co chwil\u0119 wyskakuj\u0105 mu powiadomienia o nowych commitach do sprawdzenia. Z drugiej strony \u2013 autor kodu te\u017c nie jest zadowolony: czeka na feedback, nie mo\u017ce przej\u015b\u0107 do kolejnego zadania, bo boi si\u0119, \u017ce b\u0119dzie musia\u0142 du\u017co przerabia\u0107. To b\u0142\u0119dne ko\u0142o.<\/p>\n
Jak to naprawi\u0107?<\/strong><\/p>\n Po pierwsze, ustal limity WIP (Work In Progress)<\/strong>. To prosta zasada z Kanbana: nie pozw\u00f3l, \u017ceby w jednym czasie by\u0142o otwartych wi\u0119cej ni\u017c kilka pull request\u00f3w na osob\u0119. Kiedy senior widzi, \u017ce ma ju\u017c 2 otwarte review, nie bierze nowych zada\u0144, dop\u00f3ki ich nie domknie. To zmusza do tego, \u017ceby \u201eczy\u015bci\u0107\u201d backlog review na bie\u017c\u0105co.<\/p>\n Po drugie, wyznacz sta\u0142e okna na code review<\/strong>. W jednym z projekt\u00f3w wprowadzili\u015bmy zasad\u0119: codziennie rano godzina 10:00\u201311:00 to czas tylko na review. Nikt wtedy nie planuje innych spotka\u0144. Efekt? \u015aredni czas oczekiwania na review spad\u0142 z 3 dni do 4 godzin. Ludzie zacz\u0119li planowa\u0107 swoj\u0105 prac\u0119 tak, \u017ceby wyrobi\u0107 si\u0119 przed tym oknem, co dodatkowo zdyscyplinowa\u0142o ca\u0142y zesp\u00f3\u0142.<\/p>\n To nie s\u0105 rewolucyjne pomys\u0142y \u2013 to zdrowy rozs\u0105dek. Ale ma\u0142o kto o to dba.<\/p>\n Drugi cz\u0119sty b\u0142\u0105d to traktowanie code review wy\u0142\u0105cznie jako \u201e\u0142apania b\u0142\u0119d\u00f3w\u201d. Oczywi\u015bcie, \u017ce powinni\u015bmy wy\u0142apywa\u0107 problemy, ale je\u015bli to jedyny cel, to przegrywamy co\u015b znacznie wa\u017cniejszego \u2013 dzielenie si\u0119 wiedz\u0105 i sp\u00f3jno\u015b\u0107 architektury.<\/p>\n Znasz to powiedzenie? Programowanie to praca zespo\u0142owa.<\/em> Code review to moment, w kt\u00f3rym mo\u017cesz przekaza\u0107 kontekst biznesowy, podzieli\u0107 si\u0119 lepszym rozwi\u0105zaniem albo pokaza\u0107 m\u0142odszemu koledze, jak unikn\u0105\u0107 pu\u0142apek. Je\u015bli recenzent tylko pisze \u201eOK\u201d, to zmarnowana szansa.<\/p>\n Pami\u0119tam sytuacj\u0119, gdy jedna z firm mia\u0142a ogromne problemy z d\u0142ugiem technologicznym \u2013 ka\u017cdy pisa\u0142 kod po swojemu, by\u0142 chaos. Wystarczy\u0142o, \u017ce zacz\u0119li\u015bmy traktowa\u0107 code review jako przestrze\u0144 do egzekwowania standard\u00f3w \u2013 patrzenia, czy nowy kod pasuje do architektury, czy nie wprowadza niepotrzebnych zale\u017cno\u015bci, czy nie duplikuje istniej\u0105cych rozwi\u0105za\u0144. Od razu poprawi\u0142a si\u0119 jako\u015b\u0107, a zesp\u00f3\u0142 zacz\u0105\u0142 uczy\u0107 si\u0119 od siebie nawzajem.<\/p>\n Jak to naprawi\u0107?<\/strong><\/p>\n Przygotuj checklist\u0119 przegl\u0105du kodu<\/strong> \u2013 nie po to, \u017ceby j\u0105 \u015blepo wype\u0142nia\u0107, ale \u017ceby nie zapomnie\u0107 o wa\u017cnych aspektach: bezpiecze\u0144stwo, wydajno\u015b\u0107, zgodno\u015b\u0107 z konwencjami, testy. Rozbij review na kategorie: logika, architektura, styl, testy. Dzi\u0119ki temu recenzent wie, na czym si\u0119 skupi\u0107 w pierwszej kolejno\u015bci.<\/p>\n Po drugie \u2013 staraj si\u0119 zostawia\u0107 komentarze, kt\u00f3re edukuj\u0105, a nie tylko oceniaj\u0105<\/strong>. Zamiast \u201etu jest \u017ale\u201d \u2013 napisz \u201eto rozwi\u0105zanie mo\u017ce nie zadzia\u0142a\u0107, bo\u2026 lepiej b\u0119dzie zrobi\u0107\u2026\u201d. To buduje zaufanie i sprawia, \u017ce ludzie chc\u0105 si\u0119 dzieli\u0107 kodem.<\/p>\n Trzeci grzech to ignorowanie narz\u0119dzi, kt\u00f3re mog\u0105 odci\u0105\u017cy\u0107 ludzki m\u00f3zg. Wi\u0119kszo\u015b\u0107 zespo\u0142\u00f3w nadal r\u0119cznie sprawdza rzeczy, kt\u00f3re powinien robi\u0107 linter czy statyczna analiza kodu. Przez to trac\u0105 czas na szukanie b\u0142\u0119d\u00f3w w formatowaniu, podczas gdy powinni skupi\u0107 si\u0119 na logice.<\/p>\n Znam firmy, w kt\u00f3rych code review trwa godzinami, bo recenzenci tocz\u0105 boje o spacje i \u015bredniki. To absurd \u2013 przecie\u017c od tego s\u0105 automaty. Je\u015bli Tw\u00f3j zesp\u00f3\u0142 marnuje czas na takie rzeczy, to znaczy, \u017ce nie skonfigurowa\u0142 porz\u0105dnego toolchainu.<\/p>\n Jak to naprawi\u0107?<\/strong><\/p>\n Wprowad\u017a automatyczne checki w CI\/CD<\/strong>: ESLint, Prettier, testy jednostkowe na pull requestach. Ustaw narz\u0119dzia do statycznej analizy (np. SonarQube), kt\u00f3re od razu wykryj\u0105 potencjalne problemy. Dzi\u0119ki temu recenzent dostaje pull request, kt\u00f3ry jest ju\u017c \u201eprzygotowany\u201d \u2013 mo\u017ce si\u0119 skupi\u0107 na tym, co naprawd\u0119 wa\u017cne.<\/p>\n Oczywi\u015bcie, automatyzacja nie zast\u0105pi ludzkiej oceny \u2013 ale pozwala ludziom pracowa\u0107 wydajniej. Z do\u015bwiadczenia wiem, \u017ce po wprowadzeniu automatyzacji czas po\u015bwi\u0119cany na review potrafi spa\u015b\u0107 o 30\u201340%, a poziom frustracji maleje. Warto te\u017c zadba\u0107 o to, \u017ceby pull requesty by\u0142y ma\u0142e \u2013 mniejsza zmiana jest \u0142atwiejsza do zrecenzowania i \u0142atwiej w niej wy\u0142apa\u0107 b\u0142\u0119dy.<\/p>\n Na koniec wa\u017cna kwestia \u2013 sk\u0105d wiesz, \u017ce Twoje code review dzia\u0142a? Wiele firm opiera si\u0119 na intuicji, a to za ma\u0142o. Polecam wdro\u017cy\u0107 metryki DORA<\/strong>, kt\u00f3re s\u0105 standardem w DevOps i in\u017cynierii oprogramowania.<\/p>\n Mo\u017cesz te\u017c \u015bledzi\u0107 prostsze metryki, np. \u015bredni czas oczekiwania na review. We\u017a dwa tygodnie, zmierz, ile czasu mija od otwarcia PR do pierwszej akceptacji. Zazwyczaj ju\u017c ten prosty wska\u017anik poka\u017ce, w kt\u00f3rym miejscu si\u0119 zacina.<\/p>\n Pami\u0119taj te\u017c, \u017ceby regularnie robi\u0107 retrospektywy dotycz\u0105ce processu review<\/strong>. Niech zesp\u00f3\u0142 sam oceni, co dzia\u0142a, a co nie. Mo\u017ce si\u0119 okaza\u0107, \u017ce ludzie wol\u0105 pair programming zamiast asynchronicznych review \u2013 i to te\u017c jest dobry model, tylko trzeba do niego dojrze\u0107.<\/p>\n Code review to nie z\u0142o konieczne \u2013 to inwestycja w jako\u015b\u0107 kodu i wiedz\u0119 zespo\u0142u. Ale tylko wtedy, gdy robi si\u0119 to dobrze. Wprowad\u017a limity WIP, sta\u0142e okna na review, automatyzuj to, co si\u0119 da, i mierz efekty. Twoi developerzy odzyskaj\u0105 czas, a Ty zyskasz szybsze i stabilniejsze wdro\u017cenia.<\/p>\n Je\u015bli chcesz zobaczy\u0107, jak to wygl\u0105da w praktyce \u2013 przyjd\u017a do JurskiTech. Pomagamy firmom usprawni\u0107 procesy wytwarzania oprogramowania, od code review po pe\u0142ny pipeline. Napisz do nas, porozmawiajmy o Twoim zespole. Mo\u017ce okaza\u0107 si\u0119, \u017ce tracisz mniej czasu, ni\u017c my\u015blisz \u2013 ale lepiej to sprawdzi\u0107, prawda?<\/p>\n","protected":false},"excerpt":{"rendered":" Czy Tw\u00f3j zesp\u00f3\u0142 developer\u00f3w traci czas na przegl\u0105dy kodu? Pami\u0119tam projekt sprzed kilku lat \u2013 platforma e-commerce dla \u015bredniej wielko\u015bci sklepu z odzie\u017c\u0105. Zesp\u00f3\u0142 6 developer\u00f3w, sprinty dwutygodniowe, a mimo to ka\u017cdy feature wchodzi\u0142 na produkcj\u0119 z op\u00f3\u017anieniem. Kiedy usiedli\u015bmy do analizy, okaza\u0142o si\u0119, \u017ce nie chodzi\u0142o o pisanie kodu \u2013 to sz\u0142o ca\u0142kiem sprawnie.<\/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":[497,1112,1110,1111,9],"class_list":["post-2936","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-code-review","tag-code-review-automation","tag-developer-efficiency","tag-dora-metrics","tag-jurskitech"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2936","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=2936"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2936\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2936"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2936"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2936"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}B\u0142\u0105d 2: Review jako polowanie na b\u0142\u0119dy<\/h3>\n
B\u0142\u0105d 3: Brak automatyzacji w review<\/h3>\n
Jak mierzy\u0107 skuteczno\u015b\u0107 code review?<\/h3>\n
\n
Podsumowanie<\/h3>\n