Code review z korzyścią dla całego zespołu

Wprowadzenie

Wielu z nas podczas codziennej pracy nad kodem z pewnością spotkało się z wdrożonym w projekcie procesem code review. Dla jednych było to coś świetnego, dla innych zaś droga przez mękę. Natomiast zapewne większość miała nieraz do czynienia z negatywnymi efektami tego procesu i z pewnością pojawiały się wtedy wątpliwości i pytania, po co nam w ogóle to całe code review.

Jak to zazwyczaj wygląda?

Proces code review może być wdrożony na wiele różnych sposobów. Najlepsza sytuacja jest wtedy, gdy mamy z nim do czynienia w ramach prac nad projektem, w którym wszyscy programiści pochodzą z jednej firmy i wspólnie pracują nad własnym produktem. W takim przypadku każdy jest mniej więcej świadomy tego, że powstający produkt jest kluczowy dla rozwoju firmy i że każdy, kto uczestniczy w jego budowie, gra w tej samej drużynie.

Sytuacja staje się trudniejsza, kiedy pracujemy w ramach jednego zespołu, ale rozwijamy produkt dla jednego z wielu klientów naszej firmy. Wtedy programiści często nie biorą już tak dużej odpowiedzialności za projekt i tym samym nieaktualny staje się jeden z kilku czynników, który powodował, że każdy z nich chciał dostarczyć projekt w jak najlepszym stanie.

Jednakże i ta sytuacja wydaje się o wiele korzystniejsza niż scenariusz, w którym pracujemy w zespole mieszanym, złożonym zarówno z programistów naszej firmy, jak i z programistów pochodzących z innych, zewnętrznych firm, wynajętych przez klienta. W tym przypadku bardzo trudno o wspólny czynnik odpowiedzialności za projekt czy też o świadomość, że gramy do jednej bramki. Dodatkowo dochodzą jeszcze kwestie rywalizacji programistów pomiędzy firmami i ostatecznie prowadzi to do arcytrudnego zadania postawionego przed code review

Korzyści, jakie daje nam code review

Zanim jednak przejdziemy do tego, jak rozpocząć „humanizowanie” i ulepszanie procesu code review, musimy sobie wszyscy uświadomić, jakie naprawdę korzyści nam on daje. Bowiem code review to nie tylko dbanie o lepszą jakość kodu i projektu, jak większość z nas sądzi.

Przede wszystkim dzięki code review mamy okazję uczyć się programowania od innych, poznawać je z punktu widzenia innych programistów. Wiem, że wielu z nas uważa, że tylko ich rozwiązania są najlepsze. W większości wypadków tak jednak nie jest… Programowanie pozwala nam na dojście do tego samego celu na wiele sposobów, a wiele z tych sposobów jest tak samo dobrych jak nasze rozwiązania i metody, które stosujemy od lat. Najlepszym przykładem jest wojna na temat spacji i tabulatorów… Oba rozwiązania mają swoje plusy i minusy, a prawda jest taka, że oba są równie dobre – chodzi natomiast o to, aby w ramach jednego projektu stosować tylko jedno z nich.

Code review to także świetny sposób na poznawanie projektu lub bycie na bieżąco z jego rozwojem, szczególnie gdy mamy do czynienia z rozbudowanymi systemami, tworzonymi przez duże zespoły programistów. Błędny jest pogląd, że juniorzy nie powinni uczestniczyć w procesie code review w charakterze recenzentów. Wręcz odwrotnie – każdy programista z krótkim stażem lub programista dołączający do projektu powinien być wyznaczany do recenzowania każdego nowego fragmentu kodu. Tylko w ten sposób będzie miał okazję bardzo szybko zapoznać się z funkcjonowaniem całego projektu czy też z zasadami obowiązującymi w zespole. Oczywiście w takim przypadku taka osoba nie powinna być jedynym recenzentem, ale śmiało może robić pierwszą recenzję danego pull requestu / merge requestu itd., a potem zostawić go do ostatecznego zatwierdzenia przez kogoś z dłuższym stażem w projekcie i lepszą znajomością biznesu klienta.

Inną istotną korzyścią płynącą z code review jest możliwość odbycia burzy mózgów na temat danego rozwiązania i innych potencjalnych możliwości podejścia do omawianego problemu. Nikt z nas nie jest w stanie przeanalizować wszystkich scenariuszy i efektów wynikających z zastosowania danego rozwiązania. Wspólna dyskusja pomoże nam spojrzeć na kod z innej perspektywy. Ważne tylko, aby to była budująca dyskusja, z której wszyscy będą mogli wyciągnąć jakieś wnioski.

Jak zapanować nad code review

Pojawia się w takim razie pytanie, jak możemy sprawić, aby nawet code review w zespołach mieszanych, dotyczące całkiem obcego nam produktu, z którym się nie identyfikujemy, przyniosło pozytywne skutki.

Przede wszystkim powinniśmy zacząć od opracowania wspólnego dokumentu z regułami obowiązującymi w danym projekcie. Dzięki takiemu prostemu opisowi zasad będziemy w stanie wyeliminować większość zbędnych dyskusji, jakie się często toczą w komentarzach do recenzowanego kodu. W takim dokumencie powinny się znaleźć w szczególności takie informacje jak:

  • standardy kodowania,
  • opis struktury projektu i danych,
  • zasady pracy z repozytorium kodu,
  • opis procesu code review.

Jeśli nie jesteśmy pewni, co dokładnie powinniśmy zawrzeć w tym dokumencie, to warto przejrzeć archiwalne dyskusje toczące się podczas code review lub na bieżąco śledzić kolejne pull requesty i gdy tylko widzimy, że dana dyskusja jest zbędna i mogłaby zostać wyeliminowana, to opracujmy konkretną zasadę do umieszczenia w tym dokumencie lub przedstawmy cały ten przypadek jako przykład i wyjaśnijmy sposób rozwiązywania tego typu problemów.

Pamiętajmy jednak, że mimo wszystko powinien to być w miarę łatwy w odbiorze i niezbyt długi dokument. Chodzi o to, aby każdy mógł do niego wracać wielokrotnie podczas pracy z projektem, gdy tylko nie jest czegoś pewien.

Kolejna sprawa to wymuszenie na każdym członku zespołu korzystania z określonych narzędzi automatyzujących pracę, którą dotychczas wykonywaliśmy ręcznie podczas code review. Mam tu na myśli zastosowanie wszelkiego rodzaju linterów, czyli narzędzi do sprawdzania kodu pod kątem zgodności z określonymi regułami, takimi jak rodzaj wcięć w liniach, zasady dotyczące nazewnictwa zmiennych, metod itp. Jeśli wyeliminujemy rzeczy typu sprawdzanie kodu pod kątem formatowania podczas każdego code review, to nie dość, że zaoszczędzimy masę czasu, to również unikniemy wszelkich niepotrzebnych dyskusji, jakie się toczą w takich przypadkach. Po co tracić czas na coś, co może zrobić za nas „maszyna”?

Ostatnią istotną kwestią jest wskazanie osoby decyzyjnej w projekcie, która zawsze będzie miała decydujące zdanie. Taką osobą może być na przykład team leader, odpowiedzialny za zespół programistów, lub architekt, który projektuje cały system. Ostatecznie bowiem to oni biorą odpowiedzialność za wygląd całego projektu i to oni powinni wiedzieć najlepiej, co będzie najkorzystniejsze dla projektu.

Recenzent pełniący rolę mentora

Gdy wyeliminujemy już większość bardzo błahych problemów i błędów popełnianych przez programistów, to wreszcie będziemy mogli wykonywać naprawdę efektywną pracę recenzenta.

Przede wszystkim musimy zapamiętać, że rolą recenzenta w procesie code review nie jest wytykanie błędów i ganienie innych programistów. Recenzent powinien być jednocześnie strażnikiem kodu i mentorem dla innych. Tu nie chodzi o pokazywanie, że wiemy więcej od innych albo że widzimy kod w szerszej perspektywie i dostrzegamy rzeczy, o których zapomniał programista. Najgorsze, co możemy zrobić, to ślepe wytykanie błędów połączone z brakiem jakiejkolwiek informacji o tym, co można by w tym przypadku zrobić lepiej. Jeśli już widzimy, że coś jest nie tak w kodzie, to pomóżmy programiście i wskażmy mu metodę rozwiązania problemu. Nie bądźmy egoistami. Zazwyczaj większość z nas, będąc recenzentem, jest jednocześnie jednym z programistów w projekcie, więc i tak ostatecznie gramy do jednej bramki, więc jeśli ktoś zawali swój task, to odbije się to na jakości całego projektu i ocenie całego zespołu.

Duży wpływ na jakość naszej recenzji ma sytuacja, w jakiej się w danej chwili znajdujemy. Zdecydowanie nie powinniśmy podchodzić do pracy nad code review, kiedy jesteśmy przemęczeni, zdenerwowani lub zwyczajnie zmęczeni po całym dniu intensywnej pracy. Aby efektywnie wykonać code review, powinniśmy mieć zaplanowaną na to spokojną chwilę, np. z samego rana, gdy przychodzimy do pracy. Zazwyczaj jesteśmy wtedy w miarę zrelaksowani i mamy otwarty umysł na problemy, z którymi przyjdzie nam się zmierzyć podczas recenzowania czyjegoś kodu.

Jak przyjmować feedback w code review

Wielu z nas zapomina, że pracując jako programiści nad kodem, bierzemy odpowiedzialność nie tylko za sam projekt, ale często też za cały biznes naszego klienta lub za firmę, w której pracujemy, jeśli mamy do czynienia z pracą nad własnym produktem. Jest to bardzo duża odpowiedzialność, więc nawet jeśli recenzent bardzo źle oceni nasze zmiany w kodzie, to nie robi tego z niechęci do nas, lecz z chęci dbania o projekt.

Każdy z nas jest omylny, a jeśli coś zawaliliśmy, to nie bójmy się przyznać do błędu i naprawmy go po sobie. Często, gdy ktoś wytyka nam błędy, idziemy w zaparte, choć dobrze wiemy, że nie mamy racji. Musimy też nauczyć się, że czasem po prostu nie znamy perspektywy danego biznesu i nasze założenia nie zawsze będą słuszne. Niekiedy inny programista, który lepiej zna klienta i jego biznes, ma po prostu szerszą perspektywę na projekt i jest w stanie wychwycić pewne aspekty, o których my sami nawet nie pomyśleliśmy.

A co, jeśli naprawdę wierzymy i jesteśmy pewni, że mamy rację? W każdym projekcie powinna być osoba w postaci team leadera, która będzie miała decydujący głos i do której będziemy mogli się w takiej sprawie zwrócić. Team leader bierze ostateczną odpowiedzialność za cały projekt, więc musimy mu po prostu zaufać i zaakceptować decyzje, które on podejmuje.

Podsumowanie

Pamiętajmy przede wszystkim, że code review to nie czas na kłótnie, a na budującą dyskusję, w której każdy powinien być otwarty na argumenty drugiej strony. Nie jest to również okazja do przepychanek pomiędzy zespołami programistów z różnych firm.

Każdy z nas powinien przyłożyć się do code review – zarówno recenzent, jak i osoba recenzowana. Najgorsze bowiem, co możemy zrobić, to przepychanie się w komentarzach i przedkładanie kłótni nad pracę nad kodem i wdrażanie nowych rozwiązań.

Maciej Mortek

To też Cię może zainteresować