Kto powinien robić recenzje kodu?

W mojej firmie głównie architekt dokonuje przeglądów kodu. Jest bardzo doświadczonym i inteligentnym facetem od oprogramowania, więc jest w tym bardzo dobry. Gdy programiści dokonują recenzji kodu, nie robią tego również w połowie. Próbowaliśmy dać programistom więcej recenzji kodu, ale jakość recenzji kodu nie była dobra. Używamy Scrum jako metodyki rozwoju.

Jednak w obecnym systemie występują dwa problemy:

1. Architekt staje się wąskim gardłem

2. Programiści nie biorą odpowiedzialności za jakość kodu i architektury (co prowadzi do różnego rodzaju problemów).

Jak możemy rozwiązać te problemy? Czy powinniśmy zmienić, kto ocenia kod?

Programiści powinni przeprowadzać recenzje kodu. Powinni robić recenzje kodu, ponieważ powinni znać kod, standardy i praktyki w stylu firmy. Zlecając innym osobom przeglądanie kodu, informujesz programistów, że nie jest odpowiedzialny za to, aby kod spełniał standardy firmy.

Jeśli uważasz, że potrzebują szkolenia z robienia recenzji kodu, zdobądź je dla nich. Biorąc pod uwagę twoją obecną sytuację, możesz poprosić programistę o wykonanie przeglądu kodu, a następnie o skomentowanie tego przez architekta - poproś programistę o przesłanie recenzji architektowi do zatwierdzenia przed wysłaniem go do osoby przesyłającej.

W tej sytuacji potrzebujesz wiedzy tego doświadczonego programisty, aby pomóc reszcie zespołu się rozwijać. O jakości zespołu nie decydują umiejętności najlepszego programisty; zależy to od umiejętności najgorszych. Możesz wypróbować takie rzeczy jak:

• Recenzje współpracy. To działało naprawdę świetnie w moim ostatnim zespole. Umieściliśmy cały zespół w pokoju z projektorem i zaczęliśmy przeglądać niektóre elementy. Być może na początku architekt jest tym, który prowadzi przegląd, ale za kilka tygodni (zarezerwowaliśmy jedną lub dwie godziny w każdy piątek) cały zespół zaczyna mówić i rozumieć kluczowe koncepcje, które obecnie zna tylko architekt.

• Programowanie w parach. Dla mnie jest to najlepsze narzędzie do rozpowszechniania wiedzy w zespole.

Chociaż widzę sens, by architekt systemu / oprogramowania podpisywał wszystkie zmiany / zatwierdzenia, programiści powinni mieć możliwość dokonywania recenzji bez angażowania architekta - z wyjątkiem arbitrażu.

Moje preferowane [*] procedury przeglądu to:

• Grupuj zmiany według wymagań / problemów.
• Zaproś wszystkich programistów, architekta oprogramowania i autora wymagania / problemu do przejrzenia. (Nie wszystkie są wymagane do dokonania przeglądu).
• Uważaj recenzję za zakończoną, gdy:
  • Dwóch programistów zrecenzowało.
  • Odpowiedzi na wszystkie komentarze. (Możliwe, że architekt oprogramowania podejmie decyzję).
  • Minął jeden dzień roboczy bez dalszej dyskusji (lub wszystkie zaproszone strony dokonały przeglądu).

Więc moja krótka odpowiedź na twoje pytanie brzmi: programiści powinni zmieniać recenzje.

[*] Niestety nie zawsze tak działają projekty, w których biorę udział.

Podoba mi się praktyka sporadycznych przeglądów kodu zespołu, które obejmują cały zespół architektów, ale potem mnóstwo i wiele recenzji kodu między dwoma lub trzema członkami zespołu.

Jeśli to naprawdę trudny lub wrażliwy kod, zwróć się do architekta lub starszych członków zespołu.

Szczerze mówiąc, brzmi to trochę absurdalnie, gdy architekt dokonuje przeglądu kodu. Powinien przeprowadzać nieformalne przeglądy projektów lub sporadyczne przeglądy kodu, aby podzielić się swoją wiedzą. Zespół inżynierów powinien wziąć odpowiedzialność za kod. Jeśli pojawią się problemy, z czasem staną się lepsze.

Zgadzam się, że jeśli tylko jedna osoba dokona recenzji, reszta facetów prawdopodobnie po prostu powie: „Nie wiem, wydaje się, że działa, ale pozwól temu inteligentnemu facetowi dowiedzieć się, czy jest w porządku, czy nie”. Mogę myśleć o następujących kwestiach:

• upublicznij swój kod, aby każdy mógł zobaczyć, nad czym wszyscy pracują; wypisz nazwy na początku każdego pliku zawierającego kod; może wydrukuj je i wytłocz je w łazience lub gdziekolwiek czujesz, że przyciągnie wzrok
• programowanie par; z innym mózgiem obok ciebie, pomyślisz dwa razy przed nazwaniem swojej zmienneji
• podnieś dozorcę i wyjaśnij mu, jak działa to dziedzictwo (och, tak, to nie działa). Wyjaśnienie kodu komuś innemu pomaga. Może się kompiluje, może robi właściwe rzeczy, ale tak naprawdę nie rozumiesz dlaczego. Teraz masz szansę
• mieć zestaw wytycznych i sprawić, by wszyscy je przestrzegali; bez względu na wytyczne, jest to lepsze niż brak wytycznych