Załóżmy, że pracujemy w hipotetycznej firmie, która ma kilku programistów, którzy rzadko pracowali razem nad projektami, a Szef nie wierzył, że recenzje kodu są warte czasu i kosztów.
Jakie są różne argumenty, które można przedstawić w tym scenariuszu, które przedstawią zalety przeglądu kodu? Ponadto, jakie są potencjalne argumenty przeciwko przeglądowi kodu tutaj i jak można temu przeciwdziałać?
programming-practices
code-reviews
tips
Kevin D.
źródło
źródło
Przegląd kodu może zaznajomić wielu programistów z tym samym kodem. To coś dobrego. Co jeśli oryginalny autor zdecyduje się rzucić lub gorzej, coś mu się stanie. Jeśli przeglądy kodu są przeprowadzane regularnie, inni mogą szybko przejąć kontrolę.
Uczestnicy mogą być w stanie wykryć potencjalne błędy lub problemy z wydajnością podczas przeglądania kodu. Zmniejsza to QA i wysiłek rozwojowy. Może to zrekompensować dodatkowe koszty związane z przeglądami kodu.
Recenzje kodu promują dzielenie się wiedzą. Rówieśnicy mogą powiedzieć lepsze lub alternatywne sposoby robienia rzeczy. Sam wiele się nauczyłem od moich kolegów poprzez przeglądy kodu.
Recenzje kodu pomagają wzmocnić wytyczne dotyczące kodowania, a następnie zespół. Jeśli zespół go nie ma, należy to naprawić. Kod ma być napisany raz i przeczytany wiele razy. Wskazówki dotyczące kodowania są krokiem w kierunku czytelnego kodu. Kod powinien być czytelny dla użytkowników. Czy jest lepszy sposób niż przeglądanie kodu w celu zapewnienia czytelności?
źródło
Wiele świetnych odpowiedzi tutaj. Niektóre rzeczy, które chciałbym dodać:
Gdy musisz wyjaśnić kod komuś innemu, często w trakcie wyjaśniania deweloper może nagle zdać sobie sprawę, że ma błąd. Widziałem to raz po raz, że deweloper zatrzymuje się martwy w swoich śladach i mówi „och, czekaj, to źle”, zanim recenzent zrozumie to wystarczająco dobrze, aby zobaczyć błąd.
Znajomość twojego kodu zostanie sprawdzona przez kogoś innego, daje ci większą motywację do korzystania ze standardów kodowania (ułatwiając konserwację) lub korzystania z mniej „kowbojskich” metod, których nikt poza tobą (a czasem nawet tobą) nigdy nie zrozumie. Nie chcesz się wstydzić, kiedy pokazujesz swój kod komuś innemu, więc lepiej go wykonasz. Z powodu czynnika zakłopotania pozostawia mniej kodu komentowanego: „Nie wiem, dlaczego to działa, ale nie zadzieraj z tym”. w bazie kodu.
Programiści, którzy potrzebują szerszego nadzoru lub szkolenia, są łatwo identyfikowani. Tak samo są niekompetentni. Im szybciej znajdziesz i rozwiążesz problemy z wydajnością, tym lepiej dla całego zespołu i tym wyższa będzie jakość aplikacji. Dobrze jest znaleźć te informacje, zanim weźmiesz nowego faceta, który potrzebuje szkolenia, i przydzieli go do najtrudniejszej, najbardziej krytycznej części twojej aplikacji.
Czasami jest to tylko kwestia skorygowania nieporozumienia, które pozwoli zaoszczędzić popełnienia tego samego błędu w wielu innych miejscach. Na przykład ostatnio przeglądaliśmy niektóre SQL pod kątem złożonych raportów i stwierdziliśmy, że kilku naszych nowych deweloperów miało to samo nieporozumienie co do tego, gdzie znaleźć konkretną informację w bazie danych (wprawdzie miejsce, które wybrali, wydawało się logiczne, co jest kwestią projektu bazy danych też trzeba to naprawić), co miałoby kluczowe znaczenie dla poprawnego napisania wszystkich raportów. Po znalezieniu problemu i naprawieniu go w pierwszych raportach, które napisali, udało się uniknąć tego samego błędu w pozostałych raportach. I coś, co starsi (z czasem pracujący tutaj nie starzejący się) deweloperzy byli tak przyzwyczajeni, że nie sądzili, że trzeba to wyjaśnić.
Juniorzy mogą uczyć się na bardziej zaawansowanym kodzie napisanym przez seniorów (którzy na przykład lepiej rozumieją wychwytywanie błędów i przypadki brzegowe), a seniorzy mogą uczyć się na podstawie nowych technik stosowanych przez juniorów, na które jeszcze nie byli narażeni.
Czasami ludzie pracujący nad różnymi, ale powiązanymi częściami aplikacji, zdają sobie sprawę, że idą w dwóch różnych i wzajemnie się wykluczających kierunkach. Ups, teraz łatwiej to naprawić.
Nie jest tak łatwo wkraść się w wartości zakodowane na stałe, które z czasem będą się zmieniać, aby wszystko zaczęło działać. Zapobiega to wielu przyszłym błędom, takim jak rzeczy, które zmieniają się na początku każdego roku obrotowego.
Czasami utknąłem, jak coś zrobić i nauczyłem się nowej techniki, której właśnie chciałem od kodu recenzującego czyjeś rzeczy.
Jeśli znasz sposób, w jaki myślą inni członkowie zespołu (który przegląd kodu pomoże ci to zrozumieć), łatwiej będzie później rozwiązać problemy, ponieważ zaczniesz od zrozumienia, w jaki sposób Joe podszedłby do tego rodzaju podejścia problem.
źródło
Oprócz dzielenia się wiedzą, o której wspominali inni, znajdź przykłady błędów, które zostałyby znalezione podczas przeglądu kodu i zmierzyć, ile czasu zajęło ich naprawienie - obejmuje to czas poświęcony na zbadanie problemu i wydanie poprawionej wersji, a także faktyczny czas naprawienia błędu.
Weź ten koszt, który prawdopodobnie będzie wymagał co najmniej kilku dni, i porównaj go z czasem, który poświęciłbyś na przegląd kodu i działanie na wyniki.
To pokaże szefowi, że recenzje kodu są warte tego kosztu.
źródło
Recenzje kodu mogą:
Cons
Jeśli to prawda, to dlaczego zawsze wydaje się, że mamy czas zrobić to dwa lub trzy razy dla tego samego klienta, ale nigdy nie mamy wystarczająco dużo czasu, aby zrobić to dobrze za pierwszym razem.
źródło
Jeśli potrzebujesz odwołać się do dokumentu, nie będę szukał dalej niż ceniony „Kod ukończony”. Książka opisuje w nim liczbę błędów wykrytych podczas testów jednostkowych w porównaniu z recenzją. To zdumiewające. Testy jednostkowe, jeśli pamięć dobrze mi służy, wychwytują tylko ~ 30% wszystkich błędów, podczas gdy formalne oceny równorzędne wychwytują ~ 70%.
Weź te informacje, pokaż mu w książce i odwołaj się do jego strony finansowej. Przepuszczanie błędów trwa znacznie dłużej i jest znacznie droższe niż wczesne wykrywanie.
źródło
Co powiesz na uruchomienie wersji demonstracyjnej (tygodniowego projektu typu „myszki miki”) wykonanej równolegle przez dwa zespoły, jeden z wykorzystaniem przeglądu kodu, drugi nie.
Pod koniec tygodnia, oceniając jakość pracy każdego zespołu, jestem całkiem pewien, że recenzenci kodu wypadną lepiej.
źródło
Steve MCCONNEL za Construx The Business Case dla lepszego oprogramowania Praktyk i zasięgu ręki Software Software Development adres (LHF) tego. Z tego ostatniego „LHF, które nie będą się opierać kierownictwu wyższego szczebla”, wymienia Inspekcje.
źródło
Podczas prezentacji skup się na większym obrazie.
Wymień zalety (lepszy kod, mniej błędów, mniej ponownych zapisów itp.) I wymień przegląd kodu jako jedną z technik, które byś polecił.
Chciałbym uczynić to częścią większego obrazu kunsztu programistycznego
Przygotuj się do samodzielnego wykonywania wielu zadań związanych z promowaniem tych zasad.
Przede wszystkim nie oczekuje się, że perswazja będzie czymś w rodzaju „jednego spotkania i zrobionego”.
Z czasem powinieneś budować obudowę ze spokojem i konsekwencją. Kiedy najbardziej denerwują Cię błędy, które zostały naprawione za pomocą lepszych technik, często jest to najgorszy czas, aby przedstawić swoją sprawę, ponieważ istnieje większe prawdopodobieństwo, że będziesz zbyt emocjonalny i mniej racjonalny. Może się to wydawać nieco sprzeczne z intuicją, ale tego nauczyłem się przez 30 lat programowania. Oczywiście ymmv.
źródło