Recenzje kodu, jakie są zalety? [Zamknięte]

W moim zespole nie przeprowadzamy formalnych recenzji kodu. Mamy tendencję do myślenia, że ​​często wystarczy programowanie par i obracanie par.

Czy powinniśmy rozważyć przeprowadzenie formalnych recenzji kodu? Jakie byłyby zalety?

Recenzje kodu wykonujemy nieco inaczej (być może).

Wszyscy programiści spotykamy się razem (w każdy piątek) i sprawdzamy, co zrobiliśmy w ciągu kilku tygodni. Następnie wybraliśmy projekty, które chcemy przejrzeć, aby każdy projekt ukończony / w toku miał co najmniej jedną lub kilka osób. Następnie za godzinę przyglądamy się wprowadzonym zmianom, szukamy błędów, jak działają inne projekty itp. Następnie dyskutujemy, mówimy o błędach, jak należy to zrobić (nie naprawiamy błędów, po prostu je wskazujemy i spamuj kod za pomocą FIXME). Ogólnie rzecz biorąc, zwykle dla nas (10 programistów) zajmuje to około 2 godzin.

Profesjonaliści:

• Każdy członek wie, co dzieje się w firmie
• Błędy znajdują się szybciej
• Zmusza nas do napisania czytelnego kodu (kod, który można odczytać bez wyjaśnienia lub wprowadzenia!)
• Metody optymalizacji / sztuczki / programy produkcyjne rozprzestrzeniają się szybciej
• Programista jako specjalista „ewoluuje” szybciej
• Jest fajnie

To, co mam przeciwko programowaniu par, jak wspomniano (na pewno to tylko moja osobista opinia), polega na tym, że im dłużej zespół współpracuje - tym szybciej to robi.

Mam nadzieję, że przyniesie to do myślenia. Powodzenia.

Możesz przeczytać tę bezpłatną książkę:

http://smartbear.com/best-kept-secrets-of-peer-code-review/

Jasne, mają produkt do popchnięcia, ale wciąż jest tam wiele przydatnych informacji.

Dyskutują również, w jaki sposób programowanie parami zapewnia niektóre z tych samych zalet, więc jeśli programujesz w parach, możesz w ogóle nie potrzebować przeglądu kodu.

Nie mam dużego doświadczenia w recenzowaniu w twoim środowisku. Nie zajmujemy się zbyt często programowaniem par, robimy recenzje kodu, aby rozpowszechniać wiedzę o oprogramowaniu w zespole, mamy kolejną parę oczu, aby wykryć błędy i mieć formalny punkt, aby sprawdzić, czy oprogramowanie jest zgodne z naszymi wytycznymi dotyczącymi kodowania .

Pierwsze 2 punkty są dość dobrze objęte programowaniem par, trzeci jest bardzo zależny od pary i może być lepszy od formalnego przeglądu kodu.

Czy powinieneś robić formalne recenzje kodu?

Absolutnie

Krótko mówiąc, mam bardzo małe doświadczenie z programowaniem w parach, ale nie sądzę, aby recenzje kolidowały z tymi metodami.

Wprowadziłbym dwie formy recenzji kodu:

Recenzje kodu równorzędnego

Nawet jeśli programowanie w parach działa dla Ciebie, nigdy nie boli, aby uzyskać kolejny zestaw oczu na kod. Korzyści z tego są następujące:

1. Dostaje zestaw świeżego spojrzenia na kod, kogoś, kto może mieć bardziej intymną wiedzę na temat obszarów bazy kodu, z którymi ty (i / lub twój partner) nie znasz się tak dobrze. Może to ujawnić problemy z domieszką.
2. To sprawia, że ​​(para) ponownie weryfikujesz swoje rozwiązanie przed przesłaniem. Ponieważ recenzent nie wie nic o tym, co napisałeś, musisz to wyjaśnić w całości. Może to ujawnić przypadki krawędzi, o których wcześniej nie pomyślałeś, lub nieprawidłową logikę.

Przeglądy kodów równorzędnych (w moim świecie) są przeprowadzane przed każdym przesłaniem. Jak to się dzieje w świecie programowania w parach, nie jestem pewien.

Recenzje kodu grupy

Zdarza się to rzadziej niż recenzje kodów równorzędnych. Generalnie wciągałbym moją grupę (lub jej podsekcję) do pokoju konferencyjnego w celu nieformalnego przeglądu kodu. Zasadniczo wybrałbym kod napisany przez przypadkową osobę w zespole, najlepiej kod napisany od zera - zreformowany kod nie ujawnia problemów takich jak nowy kod.

Upewnij się, że wszyscy wiedzą, że te recenzje nie są przeznaczone do emberass i nie są używane do odzwierciedlenia wydajności. Mają one jedynie zapewnić przestrzeganie standardów kodowania zespołu i pomóc wszystkim być lepszymi inżynierami, a tym samym stać się bardziej użytecznymi dla zespołu (i dalszego rozwoju kariery itp.) - i upewnić się, że to jest prawdziwy cel recenzji . Jeśli ktoś podejrzewa coś innego, będą się obawiać i będą mniej produktywni.

Przeszedłem przez kod w sposób nieco nieformalny, pozwalając każdemu w pokoju wskazać różne rozwiązania, które mogą mieć, lub napotkać błędy logiczne. To ma być raczej dyskusja grupowa niż siedzący tam lider, który mówi wszystkim, jak powinni kodować.

Przekonałem się, że zastosowanie tych dwóch metod zwiększa tempo postępu inżynierów, a także znacznie zmniejsza liczbę błędów :)

Nigdy nie ćwiczyłem programowania par w praktyce (liczyłem tylko na to), więc nie mogę bezpośrednio porównać tych dwóch praktyk. Mogę jednak opowiedzieć o swoich doświadczeniach z formalnymi recenzjami kodu.

Prowadziłem formalne przeglądy kodu we wcześniejszym projekcie dotyczącym starszego kodu. Projekt był w kompletnym chaosie, a zarząd z zadowoleniem przyjął każdą inicjatywę z nadzieją wprowadzenia porządku w chaos. W tym czasie myślałem, że formalna weryfikacja kodu jest dobrym pomysłem. Znaleźliśmy błędy i zauważyliśmy, że jakość świeżo napisanego kodu była znacznie lepsza niż jakość starego kodu. Zebrałem statystyki, liczbę błędów itp., Aby to udowodnić.

Zrobiliśmy średnio jedną sesję tygodniowo, z udziałem 3-5 osób. Każda sesja trwała około 3-4 godzin na osobę (łącznie z przygotowaniami) i przejrzała 200-300 linii kodu (LOC) *. W tym tempie przez ponad 6 miesięcy udało nam się sprawdzić około 5 000 LOC, z około 50 000.

Z perspektywy czasu uważam, że było to bardzo kosztowne. Przy takim tempie zajęłoby nam 5 lat, aby przejrzeć całą bazę kodu starszego typu. OTOH mający więcej niż jedną sesję tygodniowo pozbawiłoby zasoby możliwości rozwoju. Oczywiście jest to typowy dylemat ze starszym kodem. Ale nawet przejrzenie całego świeżo napisanego kodu zajęłoby dużo czasu, znacznie spowalniając rozwój.

Doszedłem do wniosku, że formalne przeglądy kodu najlepiej przeprowadzać na nowo napisanym kodzie, koncentrując się na najbardziej krytycznych częściach kodu. Reszta jest lepiej przetwarzana w bardziej nieformalny sposób, prawdopodobnie poprzez programowanie parami. To tylko moja obecna opinia, która może się zmienić. Nie twierdzę, że jestem guru sprawdzania kodu czy coś takiego.

* Jest to normalne tempo formalnych recenzji kodu.

Typowe stawki przeglądania kodu wynoszą około 150 linii kodu na godzinę. Sprawdzanie i przeglądanie ponad kilkuset wierszy kodu na godzinę w przypadku krytycznego oprogramowania (takiego jak oprogramowanie wbudowane o krytycznym znaczeniu dla bezpieczeństwa) może być zbyt szybkie, aby znaleźć błędy.

Cytat z Wikipedii (moje podkreślenie).

Powodem, dla którego istnieją recenzje kodów, jest to, że izolowani programiści muszą się spotkać i przedyskutować swój kod i sprawdzić, czy jest on zgodny ze standardem.

Nie wspominasz o żadnych problemach z jakością, więc wygląda na to, że Twój zespół już dokonuje wystarczającej liczby przeglądów kodu za pomocą programowania par. Niesamowite!

Prawidłowo wykonane programowanie par sprawia, że formalne przeglądy kodu stają się zbędne. Ale wypróbuj to przez kilka tygodni i sprawdź, jak to działa, ale podejrzewam, że nie zauważysz żadnej poprawy.

Należy pamiętać, że recenzje kodu są męczącym, kosztownym procesem i nie należy ich lekceważyć. Zasadniczo wprowadza przekazanie do twojego projektu, które jest kosztowne i spowalnia wszystko . O wiele lepiej jest przede wszystkim upewnić się, że kod jest poprawny, niż próbować znaleźć problemy później.

Może. Recenzje kodu wymagają czasu. Są one opłacalne tylko wtedy, gdy czas poświęcony na przeglądanie zostanie zaoszczędzony w innym punkcie procesu. Jakich oszczędności oczekujesz od recenzji kodu? Czy masz problemy, którym można zapobiec dzięki przeglądom kodu?

Jeśli programujesz w parach, potrzeba przeglądu kodu znacznie się zmniejsza, ale na pewno skorzystasz z przeglądu. Aby było to korzystne, musi to zrobić osoba starsza i bardziej doświadczona niż członkowie pary.

Jakie są korzyści? Cóż, byłoby lepiej, gdybyś wziął pod uwagę ryzyko, że tego nie zrobisz.

• Para może robić coś złego lub może robić to w sposób nieoptymalny
• Być może nie przestrzegasz standardów kodowania lub nie dokumentujesz poprawnie kodu. Recenzja jest naprawdę dobra w ich znalezieniu
• Nikt inny niż para nie rozumie określonego fragmentu kodu. Co się stanie, jeśli obaj członkowie odejdą, a kod jest słabo udokumentowany? Inni będą marnować czas na próby rozwiązania tego. Posiadanie trzeciej osoby, która wie, co zrobiłeś, zmniejsza ryzyko.

Cieszę się, że ludzie powiedzieli, że przegląd kodu to strata czasu. Tak, to zajmuje trochę czasu. Może nie spowoduje żadnych zmian w kodzie, ale to nie znaczy, że jest zmarnowany. To tak, jakby powiedzieć, że nie musisz regularnie sprawdzać systemu przeciwpożarowego, ponieważ jest to strata czasu.

Dla mnie główną zaletą recenzji kodu jest to, że sprawia, że ​​ludzie piszą lepszy kod.

Wiedza o tym, że Twój kod zostanie odczytany i sprawdzony, sprawi, że będziesz bardziej świadomy czytelności i „poprawności” kodu. Kiedy wiesz, że kod idzie prosto do repozytorium i nikt inny go nie przeczyta, chyba że jest to naprawienie defektu, masz tendencję do ześlizgiwania się, jak zmiana faktury nazw pól, gdy zmienia się ich użycie, pozostawiając niewykorzystane metody na wypadek, gdyby mogły być uwzględnionym w itp. itd.