Dlaczego przeglądy kodu mają znaczenie (i tak naprawdę oszczędzają czas)

Zespoły Agile samodzielnie organizują swoją pracę, a wielu członków zespołu dysponuje podobnymi zestawami umiejętności. Taki stan zawdzięcza się częściowo przeglądom kodu. Przegląd kodu pomaga programistom poznać bazę kodu, a także nowe technologie i techniki, które poszerzają ich umiejętności.

Gdy jeden programista zakończy pracę nad zgłoszeniem, inny przegląda kod i próbuje odpowiedzieć na pytania, takie jak:

• Czy w kodzie są jakieś oczywiste błędy logiczne?
• Czy, biorąc pod uwagę wymagania, wszystkie przypadki zostały w pełni zaimplementowane?
• Czy nowe zautomatyzowane testy są wystarczające dla nowego kodu? Czy trzeba zmodyfikować dotychczasowe zautomatyzowane testy, aby uwzględnić zmiany w kodzie?
• Czy nowy kod jest zgodny z obowiązującymi wytycznymi dotyczącymi stylu?

Przeglądy kodu powinny być zintegrowane z istniejącym procesem zespołu. Jeśli na przykład zespół wykorzystuje przepływy pracy, w których gałęzie są tworzone dla poszczególnych zadań, przegląd kodu inicjuje się po napisaniu całego kodu i pomyślnym przeprowadzeniu wszystkich automatycznych testów, ale przed scaleniem kodu z gałęzią nadrzędną. Dzięki temu czas recenzenta kodu zostaje spożytkowany na te elementy, których nie da się sprawdzić maszynowo, co pozwala uniknąć wprowadzania źle napisanego kodu do głównej linii prac programistycznych.

Przeglądy kodu przyniosą korzyści każdemu zespołowi, niezależnie od stosowanej metodyki programistycznej. Jednak w przypadku zespołów Agile korzyści są zdecydowanie większe ze względu na decentralizację pracy na poziomie całego zespołu. Nikt nie jest jedyną osobą, która zna konkretną część bazy kodu. Krótko mówiąc, przeglądy kodu sprzyjają dzieleniu się wiedzą w obrębie bazy kodu i zespołu.

Istotą wszystkich zespołów Agile jest niezrównana elastyczność: możliwość pobrania pracy z backlogu i przystąpienia do jej realizacji przez każdego członka zespołu. W rezultacie zespoły lepiej radzą sobie z rozkładem pracy przy nowych zadaniach, ponieważ nikt nie jest „ścieżką krytyczną”. Inżynierowie full stack mogą realizować prace związane z frontendem, jak i stroną serwerową.

Pamiętasz artykuł dotyczący szacowania? Szacowanie jest zadaniem grupowym, a szacunki zespołu są dokładniejsze, gdy wiedza na temat produktu jest rozpowszechniona w całym zespole. Gdy do istniejącego kodu dodawane są nowe funkcje, programista odpowiedzialny za opracowanie kodu początkowego może udzielić wartościowej opinii i podać dokładne szacunki. Ponadto każdy recenzent kodu ma również styczność ze złożonością i problemami danego obszaru bazy kodu, a także ze zgłoszeniami, które go dotyczą. Recenzent współdzieli więc wiedzę oryginalnego twórcy tej części bazy kodu. Dzięki takiej praktyce otrzymuje się wiele świadomych opinii, co w ostatecznym rozrachunku pozwala uzyskać dokładniejsze i bardziej niezawodne szacunki.

Nikt nie lubi być jedyną osobą kontaktową w sprawie danego fragmentu kodu. Podobnie nikt nie chce zagłębiać się w krytyczny fragment kodu, którego nie jest autorem — zwłaszcza w przypadku awarii w środowisku produkcyjnym. Przeglądy kodu sprzyjają dzieleniu się wiedzą w zespole, tak aby każdy członek zespołu mógł przejąć stery i kontynuować rejs. (W Atlassian uwielbiamy takie metafory). Ale tak naprawdę chodzi o to, że dzięki wyeliminowaniu ścieżki krytycznej w postaci jednego programisty członkowie zespołu mogą w razie potrzeby wziąć wolne. Jeśli ślęczenie przy biurku nad systemem kontroli wersji Cię przytłoczy, przegląd kodu jest doskonałym sposobem, aby zyskać nieco wolności. Wolności, aby skorzystać z tak potrzebnego urlopu, lub wolności, aby oderwać się na chwilę i przez jakiś czas popracować nad innym obszarem produktu.

Szczególnym aspektem metodyki Agile jest fakt, że bardziej doświadczeni inżynierowie pełnią funkcję mentorów wobec nowych członków dołączających do zespołu. A przegląd kodu ułatwia nawiązanie rozmowy na temat bazy kodu. Często wiedzą zespołów jest ukryta w kodzie i wychodzi na jaw w trakcie przeglądania kodu. Nowi członkowie dołączający do zespołu ze świeżym spojrzeniem, patrzą na nadgryzione zębem czasu części bazy kodu z nowej perspektywy. W rezultacie przegląd kodu pozwala również uzupełnić nowe spojrzenie o dotychczasową wiedzę.

Fakt, zajmują czas. Ale nie jest to czas zmarnowany — wręcz przeciwnie.

Poniżej przedstawiamy trzy sposoby optymalizacji w tym zakresie.

W Atlassian wiele zespołów wymaga, aby każdy kod przeszedł dwa przeglądy, zanim zostanie zaewidencjonowany w bazie kodu. Brzmi jak spore obciążenie pracą, prawda? W rzeczywistości tak nie jest. Gdy autor wybiera recenzentów, bierze pod uwagę wiele osób z całego zespołu. Swoją opinię może wyrazić dwóch dowolnych inżynierów. To pozwala zdecentralizować proces, dzięki czemu nikt nie staje się wąskim gardłem, i zapewnia odpowiednią liczbę osób w zespole, które mogą wykonać przegląd kodu.

Wymóg przeglądu kodu przed scaleniem z gałęzią nadrzędną daje pewność, że żaden kod nie pozostanie niesprawdzony. To z kolei oznacza, że wątpliwe decyzje dotyczące architektury podejmowane o 2:00 nad ranem oraz niewłaściwe zastosowanie wzorca fabryki przez stażystę zostaną wychwycone, zanim przyniosą trwałe (i godne pożałowania) skutki dla Twojej aplikacji.

Gdy programiści mają świadomość, że ich kod zostanie sprawdzony przez innego członka zespołu, dokładają dodatkowych starań, aby zapewnić, że wszystkie testy kończą się pomyślnie, a kod jest opracowany w możliwie jak najlepszy sposób, aby przegląd przebiegł sprawnie. Taka uważność często przyczynia się również do usprawnienia, a w konsekwencji także przyspieszenia samego procesu tworzenia kodu.

Nie czekaj na przegląd kodu, jeśli potrzebujesz informacji zwrotnych na wcześniejszym etapie cyklu programistycznego. Częste i wczesne gromadzenie opinii pozwala tworzyć lepszy kod, dlatego nie wstydź się angażować innych, niezależnie od postępu Twoich prac. Dzięki temu jakość Twojej pracy będzie lepsza, ale równocześnie inni członkowie Twojego zespołu będą lepszymi recenzentami kodu. I tak toczy się to koło sukcesu…