Jak radzić sobie z brakiem recenzji kodu w moim nowym miejscu, kiedy pochodzę z tej praktyki?

Zespół w mojej nowej firmie nie ma procesu sprawdzania kodu.

Pochodzę z firm, w których weryfikacja kodu jest obowiązkową kulturą, dlatego nie czuję się komfortowo, popełniając mój kod bez sprawdzenia go przez kogoś.

Jestem głęboko przekonany, że przegląd kodu jest sposobem na poprawę jakości i oszczędność czasu, ponieważ wcześniej wychwytuje potencjalne problemy (uwaga: nie mówię jednak o programowaniu par).

• Jak mogę pokazać, że przegląd kodu nie jest marnowaniem czasu, ale oszczędnością czasu?
• Czy przegląd kodu można pominąć, jeśli masz testy jednostkowe?

Czy przegląd kodu można pominąć, jeśli masz testy jednostkowe?

Ale dlaczego?

Podstawową rolą recenzowania nie jest wykrywanie błędów.

Tak, możesz zidentyfikować niektóre potencjalne błędy i wątpliwy, podatny na błędy kod, co często się zdarza, ale czasami wykrycie pewnych błędów nie oznacza, że ​​wzajemna ocena jest niezawodnym sposobem wykluczenia obecności błędów. Daleko od tego. To nie jest właściwe narzędzie do weryfikacji poprawności funkcjonalnej wdrożenia.

Przegląd kodu wymusza jednak jego konserwację . Będę wymagał, aby kod był czysty i zrozumiały (nie tylko dla jego autora), zanim wejdzie do produkcji.

Obecność testów jednostkowych jest całkowicie ortogonalna. Możesz mieć 100% pokrycia kodu i wszystkie testy przechodzą na całkowicie niezrozumiały kod.

Przegląd kodu służy również do zapoznania innych programistów z Twoją pracą, aby wiedzieli, co jest w stanie, i mogli stamtąd odbierać, lub obsługiwać raporty o błędach podczas wakacji itp. Wiedza o tym, co zrobiłeś od razu, może im pomóc dobrze wykonują swoją pracę - utrzymuj spójność bazy kodu (trzymaj się podobnych wzorców i konwencji w całej aplikacji) lub unikaj powielania kodu.

W szerszym ujęciu rzeczy uczy się i rozwija jako programista, czytając kod innych osób.

Testy jednostkowe nie mogą zastąpić żadnego z nich. Tak, jeśli są dobrze napisane, czytają jak dokumentację i powinniśmy do tego dążyć. Ale znowu nie wyklucza się to wzajemnie z przeprowadzaniem wzajemnej oceny, wręcz przeciwnie - wszystkie zalety wzajemnej oceny są nadal aktualne, fakt, że twoi rówieśnicy mają kilka fajnych testów jednostkowych, które sprawią, że proces recenzowania będzie łatwiejszy i jeszcze bardziej korzystny zamiast zbędnych.

Czy są jakieś badania i statystyki pokazujące, że przegląd kodu nie jest marnowaniem czasu, ale oszczędnością czasu?

Nie znam żadnego. Trudno też prowadzić takie badania, ponieważ potrzebne byłyby dwa zespoły, które mają zadanie o równej i realistycznej złożoności do wykonania, w którym jeden używa recenzji kodu, a drugi nie. Prawdopodobnie będziesz musiał poprosić ich o rozwiązanie tego samego problemu, co oznacza wyrzucenie dużej ilości pieniędzy przez okno. I trzeba by powtarzać eksperyment wystarczająco często, aby uzyskać trafność statystyczną, co zwiększyłoby ilość wyrzucanych pieniędzy o rzędy wielkości.

Jeśli po prostu zmierzysz wydajność firm korzystających z recenzji kodu w stosunku do firm, które tego nie robią, nie tylko nie będzie jasne, jak zmierzyć wydajność, ale także jaka jest rzeczywista przyczyna. Recenzje kodu są częścią większej kultury. Trudno powiedzieć, która jego część sprawia, że ​​zespół jest bardziej wydajny (i może zależeć od charakteru zespołu lub projektu). Lub obecność tej kultury może po prostu oznaczać, że firma jest mniejsza lub młodsza, a każda z nich ma wiele efektów. A może po prostu chęć poddania się przeglądowi kodu wyklucza lub promuje zdrowy dystans do twojego ego;)

Ale nie zapomnij: możesz czerpać z własnego doświadczenia. To po części dlatego cię zatrudnili. Więc jeśli naprawdę wierzysz, że możesz zwiększyć efektywność (a twój zespół rzeczywiście cierpi na jej brak), to przekaż to jasno.

Czy przegląd kodu można pominąć, jeśli masz testy jednostkowe?

Nie. Jeśli wierzysz w ważność testów, to tak naprawdę twoje testy powinny być pierwszą rzeczą do sprawdzenia. Co jeśli są nonsensowne? A jeśli zasięg jest kiepski? A może raczej testują implementację niż zachowanie?

Z niektórych przypadkowych slajdów, które znalazłem , ale twarde dane pochodzą z książki Code Complete Steve'a McConnella:

Czy recenzje kodu są przydatne?

„Uważam, że recenzje kodów równorzędnych to jedna z największych rzeczy, które możesz zrobić, aby ulepszyć swój kod”

Jeff Atwood z Coding Horror na http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html

---

„Indywidualne kontrole zwykle wykrywają około 60 procent defektów, co jest wyższe niż w przypadku innych technik, z wyjątkiem prototypowania i testów beta na dużą skalę”.

Steve McConnell, Code Complete 2nd Edition, strona 485

Ta 60% pochodzi z dokumentu IEEE Shull i in. 2002 Czego się dowiedzieliśmy o zwalczaniu wad, który zawiera sekcję zatytułowaną:

„Wzajemne oceny wyłapują 60% wad”

Uwaga: Ta odpowiedź jest moim osobistym doświadczeniem :)

Zrobiłem bardzo złe doświadczenia z recenzjami kodu w kodzie, który utrzymujemy. Ponieważ zwykle mamy tylko jedną linijkę i nie ma wiele do recenzji.

Ale w rzeczywistych projektach robiłem dobre doświadczenia, podczas mojego egzaminu mój trener regularnie sprawdzał mój kod i bardzo pomogło mi znaleźć błędy, które popełniłem bardzo często, których już nie popełniam.

Powiedziałbym więc, że to zależy od tego, co robisz, ilu ludzi jesteś itp.

Ryzyko, że twoje podsumowania kodu zakończą się wojną, nie jest niedoceniane.

Możesz poprosić swojego kierownika zespołu i / lub kolegę o sprawdzenie kodu, nawet jeśli recenzje kodu nie są wykonywane normalnie, być może w ramach szkolenia.

Przed sprawdzeniem upewnij się, że kod jest dobrze napisany i przetestowany.

Kiedy byłem liderem zespołu, sam przeprowadzałem przeglądy kodu nowych pracowników, aż (po pewnym czasie) przestałem znajdować błędy lub cokolwiek innego, co mogłoby skrytykować ich kod, i od tego momentu przestałbym z nimi przeglądać kod; tak by się stało, gdy:

• Nauczyli się systemów, z którymi się komunikują i nie potrzebowali moich wyjaśnień
• Nauczyli się projektować i / lub testować swój kod, dopóki nie był wolny od błędów, zanim go zobaczyłem
• Dowiedzieli się wystarczająco o moich wytycznych dotyczących stylu kodowania, które uważam za możliwe do utrzymania w kodzie

Recenzje kodu mają kilka celów:

• Znajdowanie wad w kodzie
• Transfer wiedzy między członkami zespołu

Myślę, że dobrze jest przeprowadzać recenzje kodu nowych pracowników, nawet jeśli zespół zdecyduje się pominąć recenzje kodu wśród doświadczonych członków zespołu.

Nie ma żadnej reguły kciuka, aby recenzje kodu były wykonywane na każdym opracowanym oprogramowaniu ... wszystko zależy od zakresu aplikacji, wielkości klienta i wielkości firmy. Na przykład, jeśli budujesz aplikację, w której jest to prosta aplikacja, w której w przyszłości mogą nie być wdrażane żadne dalsze wersje, wystarczą testy jednostkowe. Ale znowu przegląd kodu ma miejsce, gdy mówisz o wydajności aplikacji, w której musisz przejrzeć kod pod kątem wszelkich krótkich spadków kodu, które mogłyby zostać wykonane w lepszy sposób, aby ułatwić większą wydajność.

Przeglądy kodu są zwykle przeprowadzane, gdy zespół składa się z więcej niż 2 programistów i lidera technicznego, w którym lider techniczny chce zapewnić jakość aplikacji i upewnić się, że przestrzegane są standardy kodu, aby skalować aplikację do przyszłych ulepszeń i aktualizować ją dla różnych nadchodzące wersje.

Na przykład mamy obecnie wiele platform typu open source CMS i platformy te od czasu do czasu wydają aktualizacje, aby ulepszyć funkcje platformy, wyobraź sobie, że programista używa jednej z tych platform i nie przestrzega standardów kodowania, takich jak kodowanie twarde w plikach podstawowych, pisanie aplikacji kod w plikach szablonów, a jeśli ten kod przejdzie do produkcji, a później, gdy klient chce zaktualizować platformę do nowej wersji, nigdy nie zostanie zaktualizowany, chyba że kodowanie zostanie powtórzone zgodnie ze standardami kodowymi dla tej platformy. Tutaj staje się poważnym problemem związanym z udostępnieniem kodu do produkcji bez przeglądu kodu.

Powiedziałbym więc, że recenzje kodu wykonane przed wydaniem są koniecznością dla wszystkich profesjonalnych firm programistycznych, a wyjątki mogą dotyczyć tylko aplikacji osobistych / bardzo małej skali, w których programista jest bardzo doświadczonym programistą i ma z nim doświadczenie.

Przeglądy kodu mają zalety, które nie wynikają z samego procesu recenzowania: zawsze istnieje dylemat, aby uzyskać kod wysokiej jakości, ale utworzony w krótkim czasie. Bez recenzji kodu jesteś sam, więc możesz poświęcić jakość za wykonanie kodu w krótkim czasie. Dzięki recenzjom kodu jest ten recenzent, który nie pozwala ci uciec od niskiej jakości kodu - to jest dokładnie to, czego chcesz, zmuszony poświęcić czas na uzyskanie kodu jakości, który jest tym, czego chciałeś, a który wiesz, że skończy się to oszczędzaniem czasu, ponieważ każda godzina spędzona na pisaniu lepszego kodu to dwie godziny zaoszczędzone na debugowaniu (lub więcej).

Bez recenzji kodu jesteś sam, więc utrzymanie wysokiej jakości kodu zależy od Ciebie. Prostym rozwiązaniem jest sprawdzenie każdej dokonanej zmiany i naprawienie rzeczy niezgodnych z Twoimi standardami jakości.

Pozwala to również uniknąć okropnych sytuacji, w których recenzje kodu prowadzą do zderzeń ego - sytuacji, w której programista A użyłby metody X, podczas gdy B użyłby metody Y, więc jeśli A napisze kod, użyje metody X, recenzent B nalega na metodę Y, więc A przepisuje kod za pomocą metody Y, podczas gdy gdyby B napisał kod, a A go przejrzał, stałoby się dokładnie odwrotnie.

Jeśli jesteś zwolennikiem recenzji kodu, obawiam się, że nie ma prawdziwego substytutu. Niefortunnym i stereotypowym przypadkiem jest miejsce pracy, które nie dokonuje przeglądu kodu, ponieważ (A) nie zna praktyki i / lub (B) nie chce poświęcać czasu i wysiłku na przegląd kodu system na miejscu.

Zasadniczo, aby uzyskać to, czego chcesz, potrzebujesz zmiany kultury pracy - i to nigdy nie jest proste ani łatwe. Nie zapominaj, że nawet jeśli twoje miejsce pracy jest w 100% przekonane, że recenzje kodu są doskonałe i chcą je przyjąć, przejście do nowego sposobu pracy nadal będzie wymagało znacznej inwestycji czasu, energii i wydajności. Ta inwestycja powinna się zwrócić - ale musisz mieć wpisowe na inwestycję, a nie tylko na spłatę. Zobacz wideo Roya Osherove'a „Testowanie jednostek i TDD - jak to się stało” - wyzwania związane z przyjęciem recenzji kodu są bardzo podobne do tych z przyjęcia testów jednostkowych.

W międzyczasie zrób, co możesz, aby uzyskać jak najwięcej:

• Jeśli są inni programiści, którzy widzą wartość recenzji kodu, spróbuj sprawdzić siebie nawzajem, nawet nieformalnie.
• Jeśli masz mentora lub programistę odpowiedzialnego za twoje szkolenie, wyjaśnij mu wartość, którą widzisz w recenzjach kodu i zapytaj, czy byłby skłonny przejrzeć twój kod, przynajmniej czasami.
• Powiedz swojemu menedżerowi, że chcesz przejrzeć kod innej osoby, ponieważ pomoże ci to lepiej zrozumieć system.
• Jeśli w pewnym momencie zostaniesz liderem zespołu, możesz wprowadzić recenzje kodu lokalnie, tylko dla swojego zespołu.

Główną zaletą któregokolwiek z nich jest to, że jeśli będziesz w stanie utrzymać je z czasem, programiści wokół ciebie zaczną zauważać recenzje kodu. Będziesz skutecznie demonstrować, w jaki sposób recenzje kodu można zintegrować z istniejącą kulturą - i to otwiera drogę do zmiany kultury. Recenzje kodu pomagają , więc jeśli jesteś w stanie wykazać, że na małą skalę, otworzy to drogę innym - i całej kulturze - do naśladowania twojego przykładu.

Przestań się o to martwić - twój nowy pracodawca po prostu nie dba o recenzje kodu. Naucz się ufać własnym umiejętnościom, a nikt inny nie powie ci, że możesz wpisać kod, który napisałeś. Wkrótce nauczysz się żyć bez nudnego i żmudnego procesu sprawdzania kodu innych osób.

Postępuj zgodnie ze wskazówkami dotyczącymi stylu (lub tylko stylu), których wszyscy inni używają. Skorzystaj z własnego doświadczenia, aby zdecydować, co wymaga komentowania, jakich konwencji nazewnictwa użyć i tak dalej.

Następnie przetestuj wszystko, zanim je zameldujesz. Najważniejsze, że działa poprawnie.

Jeśli Twojemu nowemu pracodawcy nie podoba się pomysł recenzji kodu, może to wynikać z negatywnego powiązania ze staromodnymi metodologiami typu dowodzenia i kontroli i dążą do stworzenia bardziej nowoczesnego, zwinnego zestawu praktyk. W takim przypadku mogą być bardziej otwarci na pomysł programowania w parach, który zapewnia wiele takich samych korzyści i jest powszechnie uważany za bardziej dynamiczną, nowoczesną praktykę.