Czy niezbędne są recenzje kodu dla młodszych programistów?

Pracowałem w dwóch firmach, z których każda miała inną metodologię, jeśli chodzi o recenzje kodu:

W pierwszej firmie liderzy zespołów przeprowadzili przegląd kodu, który był wymagany po zakończeniu każdego modułu.

Jednak w drugiej firmie przywódcy zespołów nie byli zobowiązani do przeprowadzania przeglądów kodu, a jedynie sprawdzali, czy nie występują problemy z funkcjonalnością i projektem.

Więc jestem zmieszany. Czy proces przeglądu kodu jest naprawdę potrzebny? Jeśli tak, dlaczego? A jeśli nie, dlaczego nie?

Osobiście uważam, że każdy fragment kodu powinien przejść przegląd kodu, nie ma znaczenia, czy jesteś młodszym czy starszym programistą.

Dlaczego? Na początek twój tytuł nie mówi nic o tym, jak się rozwijasz, a starszy programista może nauczyć się czegoś od młodszego. W naszej firmie zmieniamy się, aby jeden z członków zespołu sprawdził Twój kod ... przeważnie jesteśmy razem „młodszym” i starszym razem, więc wszystkie rzeczy, o których nie mówi się na co dzień, mogą być złapany na kontynuacji. Jeśli senior nie lubi kodu juniora, powinien wysłuchać, dlaczego junior zrobił to, co zrobił, i spojrzeć na niego i sprawdzić, czy jest to realne rozwiązanie, które może być zastosowane w przyszłości ... to kwestia mądrości, bez względu na to, kim jesteś.

Jedną ważną rzeczą w przeglądzie kodu jest to, że nie jest się zbyt miłym, jeśli jesteś miłym facetem, po prostu pozwolisz ewoluować coraz bardziej niechlujny kod w systemie. Tak jak wczoraj zacząłem przerabiać kompletną aplikację napisaną przez byłego pracodawcę juniordevelopera, a mój bóg ten kod mógł potrzebować przeglądu, zanim odejdzie.

Nie rozumiem, dlaczego lider zespołu powinien tylko recenzować, ale wymaga osoby, która nie boi się wybrać „walki” o kawałek słabo rozwiniętego kodu i musi to być osoba, która dba o to, jak kod powinien być. Nie wszystkie firmy zatrudniają ludzi, którym tak naprawdę zależy na tym, co robią, a te złe jaja nie powinny mieć pozwolenia IMO na dokonywanie recenzji kodu, ponieważ prawdopodobnie tylko wzruszą ramionami i powiedzą „OK” na zły kod.

Zasadniczo przegląd kodu jest potrzebny wszystkim programistom bez względu na doświadczenie. Jest to kontrola jakości rozwoju oprogramowania i jednym z powodów, dla których Open Source może być bardzo wysokiej jakości.

EDYCJA: Powodem jest to, że recenzent kodu dzisiaj pełni dokładnie taką samą rolę jak opiekun później. Jeśli kod nie ma dziś dla niego sensu, nie będzie miał później sensu, przez co błędy będą droższe do naprawienia. Dlatego spraw, aby dzisiaj było zrozumiałe, podczas gdy programista wciąż pamięta kod. Recenzent może również zobaczyć błędy lub pominięcia, które programista przegapił.

Niestety bardzo niewielu chce to zrobić, ale z biznesowego punktu widzenia powinno to być obowiązkowe.

Pracuję w miejscu, w którym przegląd kodu jest teraz wymagany, ale nie był tak mały jak 3 lata temu. To znacznie poprawiło nasz kod i zdolność innych osób do utrzymania kodu w późniejszym czasie. Nawet starsi, bardzo doświadczeni programiści popełniają błędy, które można łatwo i cicho naprawić podczas przeglądu kodu, zanim znajdzie je QA, lub gorzej, zanim znajdzie je klient. Co najmniej jedna osoba inna niż pierwotny programista zna kod.

Często, gdy organizacja próbuje czegoś nowego, podobnie jak w przypadku przeglądu kodu, istnieje duży opór przed zmianami. Nie widziałem prawie nic z tego (byliśmy bardzo otwarci, aby uzyskać formalny dział kontroli jakości.) Z przeglądem kodu. Aby zobaczyć wartość, wystarczy tylko jedna lub dwie recenzje.

Znalazłem nowe techniki, których nie brałem pod uwagę zarówno podczas przeglądu kodu czyjejś pracy, jak i podczas sprawdzania mojego kodu. Znaleźliśmy problemy kompetencyjne z nowymi pracownikami stosunkowo szybko, dokonując przeglądu kodu, a co ważniejsze, dzięki temu, jak zareagowali na przegląd kodu. Dowiedzieliśmy się, jakie rzeczy wydają się teraz całkowicie jasne w trakcie programowania tej sekcji, która nie będzie jasna w konserwacji. To jest nieocenione. Możliwe, że jedyne, czego potrzeba, to komentarz, dlaczego coś zostało zrobione. Znaleźliśmy kilka podstawowych nieporozumień dotyczących projektu naszej bazy danych, które musiały zostać poprawione, aby raport zawierał prawidłowe informacje.

Często to, co widziałem w recenzji kodu, polega na tym, że przez samo wyjaśnienie komuś czegoś, deweloper będzie miał zapaloną żarówkę w głowie i zda sobie sprawę, że jest błąd, którego recenzent nie widział.

A chłopiec może przeglądać kod identyfikować tych kowbojskich programistów, którzy nie będą przestrzegać żadnego standardu ani używać mandatowych narzędzi i których kod będzie prawie niemożliwy do utrzymania przez nikogo innego. I może zmusić ich do skorzystania z programu lub wyjścia.

Ludzie najbardziej odporni na przegląd kodu to często ludzie, których organizacja najbardziej potrzebuje się pozbyć, ponieważ wiedzą w swoich sercach, że kod nie może przejść przeglądu kodu.

Zwinny facet powiedziałby: „Nie potrzebujesz recenzji kodu, po prostu sparuj programowanie i napisz dobre testy” :)

Przegląd kodu to dobry sposób na rozpowszechnianie wiedzy i dobrych praktyk w zespole. Z mojego doświadczenia wynika, że ​​należy sprawdzić, czy cały kod jest sprawdzany, i starać się zmieniać, kto przegląda jaki kod.

W moim obecnym zespole kod każdego jest sprawdzany jednakowo, a zarówno programista, jak i recenzent muszą zostać usatysfakcjonowani kodem, zanim będzie można go wydać. Dotyczy to w równym stopniu starszych programistów ocenianych przez więcej młodszych programistów, młodszych programistów recenzujących innych lub innych starszych programistów recenzujących się nawzajem. Jeśli recenzent nie ma doświadczenia lub nie czuje się komfortowo przeglądając jakiś konkretny fragment kodu, wówczas połączy siły z innym programistą (a może także oryginalnym programistą), aby przeprowadzić recenzję jako grupa.

Jestem w branży od ponad 20 lat, pracuję dla firm programistycznych i różnych firm i żadne z tych miejsc nie miało procesu weryfikacji kodu. Mogę jednak zrozumieć i docenić zalety posiadania takiego. Zasadniczo, jak je rozumiem, powinny być używane do zapewnienia zgodności ze standardami, których należy przestrzegać, aby inni mogli łatwiej utrzymać kod w przyszłości. Czytelność kodu można również sprawdzić w procesie przeglądu, ponieważ to również zapewni, że konserwacja może skutecznie współpracować z kodem.

Obecnie pracuję w małym sklepie, w którym jestem pojedynczym programistą. Czasami sprowadzaliśmy kontrahentów, którzy pomagali w zaległościach. Co najmniej jeden lub dwóch z tych wykonawców napisało kod, który niekoniecznie spełniał mój lub standardy firmy, ale działał dobrze i był co najmniej w pewnym stopniu zrozumiały. Kiedy zwróciłem uwagę na tę kwestię na kierownictwo, nie dbali o to, chcieli tylko wiedzieć, czy zrobi to, za co im zapłaciliśmy. Sądzę więc, że to zależy tylko od firmy i od tego, czy czysty, łatwy w utrzymaniu kod jest pożądanym produktem, czy też po prostu chcą czegoś, co dobrze pasuje do ceny.

Oczywiście jako programista i osoba, która musi utrzymywać kod, chciałbym pracować z czystym kodem zgodnym z jakimś standardem, ale nie zawsze mam ten luksus, więc robię z tego wszystko, co w mojej mocy, i radzę sobie z tym, co mam , nawet jeśli oznacza to czasem konieczność przepisania kodu w moim własnym standardzie.

Przeglądy kodu mogą identyfikować defekty wcześniej w cyklu życia oprogramowania, gdy problemy są łatwiejsze (i tańsze) do usunięcia. W SmartBear opracowaliśmy narzędzie do recenzowania kodu, a także przeprowadziliśmy wiele badań nad tym, jak sprawić, by recenzje były skuteczne. W oparciu o dane od naszych klientów, wady znalezione podczas przeglądu kodu są 8-12 razy tańsze w znalezieniu i naprawie niż wady znalezione w kontroli jakości. Już sama oszczędność kosztów sprawia, że ​​przegląd kodu jest tego warty, ale jest więcej wartości niż tylko to. Przegląd kodu jest doskonałym sposobem dla wszystkich członków zespołu na naukę i doskonalenie się jako twórcy oprogramowania.

Istnieje kilka pułapek, które mogą powodować, że przeglądy kodu stają się mniej skuteczne, i wygląda na to, że Twoja organizacja została złapana w jedną z nich. Dokonaj przeglądu kodu na temat kodu, a nie ludzi. Tytuły nic nie znaczą w recenzji kodu. Apele do władzy (musisz zrobić to po swojemu, bo jestem liderem zespołu) wyrządzają więcej szkody niż pożytku. Naucz zamiast tego. Starsi inżynierowie powinni wyjaśnić, dlaczego należy to robić po swojemu, a nie tylko tego wymagać. Jeśli masz trudności z wyjaśnieniem koncepcji, jest to również doświadczenie edukacyjne. Obaj będziecie lepszymi programistami dla włożonego wysiłku.

Myślę, że kod sprawdzający ALL CODE to przesada. Czas potrzebny na sprawdzenie całego kodu można lepiej spędzić gdzie indziej. Alterntivley Myślę, że kod krytyczny i / lub szczególnie złożone elementy wymagają przeglądu kodu, ale z pewnością nie każda linia kodu.

Moim zdaniem kod, który będzie używany przez firmę, bez względu na to, czy został napisany przez programistę Junior czy Senior, powinien być zawsze sprawdzany. Dlaczego? Bo co, jeśli kod zawiera kilka błędów? A jeśli w czasie używania tego kodu program się zawiesi? Aby temu zapobiec, cały kod powinien zostać sprawdzony przed użyciem.

Ale co z firmami, które nie sprawdzają kodu? Prawdopodobnie są to firmy, które mają wiele problemów technicznych i wiele, jak mówią konsumentom, „awarii” ;-).

Pozwól, że odpowiem na wszystkie twoje pytania:

• Tak, proces recenzji jest konieczny.
• Dlaczego? Z powodów, które podałem powyżej.

Przegląd kodu : Proces przeglądu kodu musi być dla wszystkich niezbędny. Wyjaśnię, którzy wszyscy odnoszą korzyści dzięki przeprowadzeniu przeglądu kodu, a także jakie są korzyści, jakie otrzymują.

1. Korzyści uzyskane przez firmę dzięki przeprowadzeniu przeglądu kodu: Jeśli przeprowadzany jest częsty przegląd kodu, firma może uzyskać produkty końcowe w znacznie lepiej zoptymalizowany sposób, który pomoże im zdobyć markową markę na rynku, a także pomoże firmie uzyskać lub poprawić swój obecny poziom CMMI .

2. Korzyści dla lidera zespołu dzięki przeprowadzeniu przeglądu kodu: Jak wszyscy wiemy, nauczyciel może łatwo zidentyfikować błędy, ponieważ częściej przeglądają odpowiedzi swoich uczniów, aby mogli dowiedzieć się, w jakich obszarach mogą być w stanie zrobić coś złego. podobnie lider zespołu wie również, co się dzieje w tych obszarach. Jak możemy to naprawić, a także pomóc liderowi zespołu w zdobyciu pomysłów na wiadomości od młodszego programisty.

3. Korzyści dla młodszego programisty dzięki przeprowadzeniu przeglądu kodu: młodszy programista może łatwo zdobyć pomysły dotyczące procesu recenzji kodu, a także jest w stanie uzyskać standard kodowania. Na przykład: aby stworzyć API we właściwy sposób, nauczą się standaryzacji kodowania, co może im pomóc w przyszłości, zwłaszcza gdy zajmą stanowisko na wyższym poziomie.

Więc moim wnioskiem jest, że przegląd kodu jest bardzo bardzo istotnym procesem dla wszystkich [nawet dla członka zespołu], ponieważ przegląd kodu pomaga nam poprawić nasze nieostrożne błędy w naszym kodzie, ponieważ wszyscy jesteśmy ludźmi, więc nie możemy przewidzieć, że nigdy popełniaj nieostrożne błędy w kodzie.

Jaka jest różnica w zakłócaniu pomysłów przed sprawdzeniem kodu (recenzji) lub później z powodu błędu, zbyt sprytnym / trudnym do zrozumienia lub nieprzestrzeganiem standardowych praktyk? Czy to twoje ego?

Nie możesz ukryć zalet przeglądu kodu lub czegokolwiek innego tylko dlatego, że jest on źle wdrażany przez mniej wykwalifikowanego członka zespołu, którego nie szanujesz. Przegląd kodu nie jest bardzo złożonym procesem, który jest w stanie uchwycić tylko kilku superprogramistów. Nie jestem pewien, czy jest wielu programistów lub profesjonalnych pisarzy, którzy są w stanie lub mają czas na samodzielną edycję.

Czy kilka miesięcy później wróciłeś do linii kodu i zastanawiałeś się, o czym myślałem? Byłaby większa szansa na złapanie go za pomocą recenzji kodu. Właśnie go złapałeś i jesteś tylko trochę lepszy od programisty, którym byłeś jakiś czas temu - mam nadzieję.

IMO przegląd kodu powinien być niezbędny dla wszystkich programistów, ale tylko wtedy, gdy osoby dokonujące przeglądu są kompetentne. W przeszłości kod był odrzucany w przeglądzie, ponieważ, nie żartuję SOLID, zrobiłem trochę Dependency Injection i miałem kod zorganizowany w przestrzeniach nazw i folderach zgodnie z logicznym projektem i obejmowałem niewielki pakiet testów jednostkowych zweryfikuj kod. Kod został odrzucony jako „zbyt skomplikowany” i powiedziano mi, żebym użył jednej klasy, która zmiażdżyła wszystko razem i usunęła testy, ponieważ to nie tak firma napisała kod.

Taki przegląd kodu jest bezwartościowy, ale przegląd kodu z kompetentnym zespołem może często wyjaśnić coś o projekcie (np. Dlaczego powinieneś zrobić X i Y, ale nie Z) lub wskazać rzeczywistą wadę (np. Wykonanie X spowoduje błąd Y z niewłaściwych powodów).

Oczywiście Code Review nie jest potrzebny . Z drugiej strony, nie są to również testy, ciągła integracja, kontrola źródła, zaangażowanie klienta, profilowanie, analiza statyczna, przyzwoity sprzęt, kompilacje jednym kliknięciem, śledzenie błędów, lista jest długa.

Oprócz recenzji kodu wspomniałem o narzędziach, które pomagają zapewnić jakość oprogramowania. Dzięki połączeniu umiejętności, szczęścia, czasu i determinacji; Państwo może dostarczyć wysokiej jakości oprogramowania bez żadnej z tych rzeczy, ale to jest bardziej prawdopodobne, że nie będzie .

W twoim scenariuszu nie ma się co mylić. Nie każda organizacja stosuje wszelkie najlepsze praktyki. Mogą się z tym nie zgadzać, mogą być sprzeczne z inną najlepszą praktyką, którą wdrażają, lub mogą uznać, że narzut związany z wdrożeniem jest dla nich zbyt duży w tym momencie. W zależności od okoliczności mogą to robić poprawnie lub mogą robić fałszywą ekonomię. W przypadku niektórych narzędzi (np. Kontrola źródła) stosunek zwrotu do nakładu jest tak dobry, że korzystanie z niego jest oczywiste; dla innych jest to mniej jasne.

Nie ma wątpliwości, że przegląd kodu jest praktyką, która wprowadza znaczne obciążenie. Z tego powodu organizacje będą starały się zminimalizować ten narzut, albo w ogóle go nie robiąc, albo robiąc to tylko w określonych sytuacjach (np. W przypadku młodszego członka zespołu lub szczególnie włochatej zmiany). Nie zawsze jest oczywiste, że spłaca więcej (łapanie błędów, zmniejszanie zadłużenia technicznego lub dzielenie się wiedzą) niż kosztuje. Większość tego zwrotu jest trudna do oszacowania, natomiast bardzo łatwo jest policzyć liczbę roboczogodzin, które Twoja organizacja spędza na przeglądaniu. Najłatwiejszy do oszacowania bit (zmniejszenie liczby błędów) można łatwo przypisać innym czynnikom (np. „Oczywiście ma mniej błędów, jest bardziej dojrzały”).

Gramy w piłkę nożną online w Turcji. Wielu użytkowników i mistrzów gier pomaga nam w zakresie funkcjonalności. Dają też komentarze na temat potrzebnych funkcji. Myślę więc, że jeśli masz wielu użytkowników, można przeprowadzić testy funkcjonalności, aby pomóc lub uzyskać odznaki. Współpraca twórców, mistrzów gier i użytkowników z forami, zespołami wsparcia i prywatnymi środowiskami testowymi tworzy projekt społecznościowy.

Konieczne są recenzje kodu i dzielenie się doświadczeniami między zespołem programistycznym, ale jeśli nie jest to krytyczne, nie musisz się zmuszać.

Myślę, że to, jak szczegółowa inspekcja drugiej strony zależy od twojego cyklu życia, od tego, czy jesteś bardziej zwinny, czy bardziej wodospad w swoich procesach. Myślę, że rozsądne jest wykonywanie projektów / inspekcji na wysokim poziomie, a także inspekcji projektów na bardziej szczegółowym poziomie. Myślę, że dobrze jest również zaangażować kilku członków zespołu do kontroli.

Są absolutnie niezbędne, ponieważ mają niewielkie doświadczenie.