Jak być lepszym w recenzowaniu kodu?

Po pierwsze mocno wierzę w proces sprawdzania kodu i zawsze chcę, aby ktoś inny sprawdził mój kod. Moje pytanie naprawdę koncentruje się na tym, jak mogę lepiej wykonać przegląd kodu dla kogoś innego?

Wiem, że aby dokonać przeglądu kodu, musisz mieć wiedzę na temat działania istniejącego kodu i znajomość lokalnego standardu, które uważam za bardzo dobre. Nadal mam wrażenie, że nigdy nie robię wystarczająco dobrej recenzji kodu dla innych osób. Wiem też, że niektóre osoby wydają się wykonywać lepszy kod sprawdzania pracy niż inne, więc zastanawiam się nad tymi, którzy są świetnymi recenzentami, jakich technik używasz?

Nie ma lepszego sposobu na sprawdzenie kodu. Jedyną rzeczą, którą możesz to zrobić, jest doskonalenie się dzięki nauce i doświadczeniu.

Zwykle rzeczy, które śledzę

- Use variables judiciously
- Keep things in scope loose boundaries will generate more errors
- Orient your language of coding in domain specific terms, they make more sense
- Keep loops to minimum 2 for each method if needed
- use ternary operators
- Arrange methods alphabetically
- Keep errors at handling ease
- write less but efficient code

Myślę, że można do tego dodać wiele.

zadaj sobie pytanie, co sprawia, że ​​inni są dla ciebie dobrym recenzentem?

także podczas przeglądania kodu;

• zatrzymaj się na wszystkim, czego teraz nie rozumiesz, napisz, że komentarz jest potrzebny
• określić, czy jest zgodny ze standardami kodowania: spacje, nawiasy, camelCase..etc
• sprawdź, czy obejmuje całą funkcjonalność
• wykonaj proste testowanie logiki, aby sprawdzić, czy spełnia ona warunki brzegowe itp.

Po prostu celuję

• wyjaśnienie, dlaczego potrzebna jest sugerowana zmiana. Upewniam się, że dostaję przyczynę nie tylko poprawki
• uzgodnienie formatowania kodu - aby każdy kod wyglądał tak samo / znajomo
• udostępnianie listy cech kodu, które chcesz zachować. Umieść go na wiki, aby każdy nie musiał popełniać każdego błędu raz. Aktualizuj to często.

Poza tym „wiedza na temat tego, czego szukać” to po prostu doświadczenie, praktyka i czytanie.

Z mojego doświadczenia wynika, że ​​najlepszym sposobem jest pozwolić zespołowi dziury na dokonanie przeglądu kodu. Używamy listy mailingowej zatwierdzenia w każdym projekcie, gdzie możesz śledzić każdą zmianę kodu w systemie kontroli wersji. Większość naszych programistów zasubskrybowała listę mailingową specyficzną dla swojego projektu, ponieważ są zainteresowani zmianami w kodzie.

Kiedy ktoś zauważy zły sposób w nowym kodzie źródłowym, albo wyjaśnia komisarzowi, w jaki sposób może to zrobić lepiej, jeśli komisarz jest stażystą, albo rozpoczyna dyskusję na ten temat, jeśli był to bardziej doświadczony komisarz.

Oczywiście ta metoda nie gwarantuje, że cały nowy kod jest sprawdzany, szczególnie w stresujących czasach, gdy nikt z zespołu nie ma czasu na śledzenie każdej zmiany kodu. Również nie każdy programista jest odpowiedzialny za zapewnienie, że każdy programista poprawi swoją pracę, sam nie możesz zagwarantować, że zostanie sprawdzony. Ale przynajmniej w naszych zespołach zawsze jest kierownik techniczny odpowiedzialny za jakość techniczną.

Jestem prawdziwym fanem recenzji kodu, jeśli są one zgodne z następującymi wynikami:

• każdy programista ma możliwość przejrzenia całego kodu i argumentów według swojej opinii
• nikt nie ma prawa nadużywać kodu innego użytkownika
• nie tylko zły kod aktywuje dyskusję, ale także dobry kod
• dyskusje kończą się szczęściem dla wszystkich zaangażowanych osób
• przegląd odbywa się prawie w czasie rzeczywistym, przynajmniej przed ukończeniem funkcji

Nauczyłem się, że jeśli jesteś kimś, kto przegląda każdą linię kodu i myśli, że musisz kontrolować takie rzeczy, jak jakość kodu pod względem formatowania kodu lub wydajności kodu, to jesteś bardzo nieefektywny, ponieważ robisz rzeczy, które maszyny mogą zrobić dla ty. Twoim celem powinno być stosowanie systemu ciągłej integracji, który kontroluje kompilację i jakość kodu każdego wkładu kodu. Jeśli ten system generuje raporty i wysyła je do autorów, wszystko jest idealne.

Muszę przyznać, że jeśli musisz przejrzeć kod, ponieważ musisz kontrolować lub uszeregować jakość programisty, moje sugestie nie mają sensu. W tym przypadku nie przeglądałbym również kodu źródłowego wiersz po wierszu. Chciałbym przejrzeć takie rzeczy jak:

• czy istnieją kwestie związane z bezpieczeństwem
• są używane zamierzone interfejsy API
• czy kod zastosował określoną architekturę
• czy napisał użyteczne testy (ale tylko jeśli został poinstruowany domyślnie, musiałem się nauczyć)
• Dokumentacja
• proces kompilacji
• ... i kilka innych, prawdopodobnie

Jeśli jesteś doświadczonym programistą, na pewno zawsze znajdziesz takie rzeczy, jak pętle, które możesz zrobić z lepszą wydajnością. Oczywiście warto wyjaśnić innym taką wiedzę, ale nie powinno to być częścią sesji przeglądowej. Jeśli występują znaczące problemy z wydajnością, to nie dlatego, że on (lub ona) użył mniej wydajnego wariantu typu listy.

Ponieważ początkowe pytanie brzmiało, dlaczego niektórzy wydają się robić lepszą recenzję, a inni odpowiadam, że ci ludzie mogą zrobić podgląd przed rozpoczęciem prawdziwej recenzji, co oznacza, że ​​prawdopodobnie przygotowali się samodzielnie, aby wiedzieli dokładnie, co chcą sprawdzić .

[H] czy mogę wykonać lepszą robotę, dokonując przeglądu kodu dla kogoś innego?

Zadaj im wiele pytań

Wiem, że aby dokonać przeglądu kodu, musisz mieć wiedzę na temat działania istniejącego kodu ...

Właściwie nie, nie musisz znać kodu wcześniej, aby być dobrym recenzentem.

Kilka prac temu mój pracodawca zaczął wymagać, aby wszystkie kontrole kodów były podpisywane przez recenzenta. Pracowałem głównie w GUI w C, a jednym z najlepszych recenzentów dla mnie był mój kumpel Bill. Był biegły w C, ale nigdy nie wykonał dużo pracy w GUI, a przeglądając recenzje, nie miał pojęcia, jak powinien działać mój kod.

Ale zadał wiele pytań na ten temat i musiał wyjaśnić, aby mógł zrozumieć, co zrobił mój kod i dlaczego pobudził wiele myślenia z mojej strony. Doprowadziło mnie to do znalezienia wielu dziwnych małych błędów z przypadkowymi przypadkami, a także do rozważenia innych podejść, które mogłem zastosować. Ponadto, chociaż pisałem C przez 22 lata i uważałem, że jestem dość biegły, szybko poprawiłem jakość mojego kodu.

Mimo że już tam nie pracuję, przed odprawą sprawdzam różnice i zadaję sobie pytanie: „Jakie pytania miałby o to Bill?”. I dość często w rezultacie coś zmieniam.