Jak ważne są pozytywne opinie w recenzjach kodu?

Czy ważne jest wskazanie dobrych części kodu podczas przeglądu kodu i powodów, dla których jest on dobry? Pozytywne opinie mogą być równie przydatne dla recenzowanego programisty, jak i dla innych osób biorących udział w recenzji.

Robimy recenzje za pomocą narzędzia online, więc programiści mogą otwierać recenzje pod kątem popełnionego przez nich kodu, a inni mogą sprawdzać swój kod w określonym czasie (np. 1 tydzień). Inni mogą komentować kod lub komentarze innych recenzentów.

Czy powinna istnieć równowaga między pozytywnym a negatywnym sprzężeniem zwrotnym?

Popraw jakość i morale za pomocą recenzji Peer Code
http://www.slideshare.net/SmartBear_Software/improve-quality-and-morale-using-peer-code-reviews

Rzeczy, które każdy powinien zrobić: Przegląd kodu
http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/

Oba te artykuły stwierdzają, że jednym z celów przeglądu kodu jest dzielenie się wiedzą na temat dobrych technik programowania, a nie tylko znajdowanie błędów.

Powiedziałbym, że to bardzo ważne. Kto chce iść na spotkanie i być tylko krytykowanym?

Kiedy robię recenzje kodu, mam po prostu monolog, więc kiedy rozumiem, co czytam, będzie dużo „Ok, rozumiem, co to robi. Dobrze, że łączy się z tym i wywołuje że w porządku .. i ten kawałek zależy od obu tych elementów. ".

Myślę, że w ten sposób nie jest to „oo la la to takie wspaniałe!”, Może to być zupełnie trywialny nudny kod, ale słuchanie, jak ktoś naprawdę analizuje i pokazuje zrozumienie tego, co napisałeś, jest formą pozytywnej opinii samej w sobie, informacja zwrotna brzmi „Ten kod ma sens”, kiedy napotykam na części, których nie rozumiem, proszę o wyjaśnienie, a kiedy go rozumiem, wykrzyknę „Ach, rozumiem”.

Myślę, że proste przekazanie zrozumienia jest pochwałą dla innego inżyniera, ponieważ wszyscy chcemy, aby nasz kod był zrozumiały dla innych, daje on formę ukrytej weryfikacji.

To powiedziawszy, jeśli widzisz części kodu, które mają dobre lub pozytywne cechy (nawet nudny, trywialny kod może być dobry, jeśli jest to jego minimalna forma) zdecydowanie zdecydowanie stwierdzam te cechy, ponownie nie przypisuję ich jako „Wow świetny!" tyle, że „widzę, że jest to minimalna implementacja” lub „Ok, ten złożony algorytm ma wiele komentarzy”, skupiając się na atrybutach kodu, nie tyle na jego wrodzonej dobroci czy złości.

Za każdym razem, gdy przypisujesz „dobroć” lub „zło” kodowi w przeglądzie kodu, aby uniknąć sytuacji, w której inżynier czułby się zlekceważony lub trzymany na piedestale, nie mów, że coś jest dobre lub złe, ale raczej omów przyczynę i skutek ich kod.

„Ok, ta część ma sens, ah, tutaj jest magiczna liczba, znaczenie tej wartości może być niezrozumiałe dla następnego inżyniera, który by ją dotknął”

„Widzę, że masz tutaj pojemnik DI, więc będziesz mieć luźne połączenie z tym repozytorium”

„Ach, tutaj jest słownik statyczny, jeśli wiele wątków dotyka tego słownika, moglibyśmy napotkać warunki wyścigu”

Zauważ, że nie mówię, że coś jest dobre lub złe, ale to, czy inżynier powinien to zmienić, czy nie, zrozumie inżynier, którego kod jest sprawdzany. Oczywiście musisz zakończyć sprawdzanie kodu z yay lub nie, ale gromadzenie tych oświadczeń w ciągu tego okresu złagodzi słowa tak, ponieważ wyjaśnienia zostały już przedstawione w formie oświadczeń przyczynowo-skutkowych, kiedy im powiesz „Chciałbym te magiczne liczby ustalone przed sprawdzeniem tego w ”.

Gdybym zobaczył coś w recenzji kodu, który naprawdę mi się podobał i który wykraczał poza „wystarczająco dobry” kod, dałbym pozytywne opinie.

Ogólnie myślę, że jeśli ktoś napisze kod częściowy, który powoduje, że mówisz „Wow, to jest naprawdę miłe!” wtedy tak, pozytywna opinia jest ważna - informuje autora, że ​​to, co zrobili, podobało się innym i powinni spróbować to zrobić ponownie. Musi jednak być czymś więcej niż tylko przestrzeganiem wytycznych i standardowych praktyk. Wyrażanie pochwały, ponieważ ktoś ładnie wciął lub dodał komentarze na płycie głównej, może ustawić poprzeczkę raczej nisko.

To nie jest tyle pytanie programistyczne, co ogólne pytanie dotyczące zarządzania i interakcji międzyludzkich. Pozytywne opinie w recenzjach kodu są tak samo ważne jak pozytywne opinie w jakiejkolwiek recenzji.

To, czy jest to wymagane (i zakres, w jakim jest to wymagane), jest funkcją usposobienia i emocjonalnego charakteru osoby, z którą rozmawiasz. Niektóre osoby reagują na korektę znacznie skuteczniej, gdy towarzyszy jej pochwała. Inni uważają pochwałę za nieszczerą, gdy jest dostarczana z poprawką.

Ogólna formuła jest czasami nazywana „Kanapką zwrotną”: najpierw dobre rzeczy, złe rzeczy drugie, dobre rzeczy ostatnie. Chodzi o to, aby utrzymać ogólny ton pozytywny, jednocześnie upewniając się, że otrzymano negatywne sprzężenie zwrotne. Może to pomóc w zapobieganiu stresowi w oczekiwaniu na przegląd, a także w zapobieganiu ponownemu wchłonięciu się lęków. Oba są bardzo ważne w odniesieniu do wydajności i jakości. To nie jest tylko emocjonalna miazga; To ludzkie zachowanie 101.

Ponownie musisz poznać osobę, z którą pracujesz i zrozumieć, na co ona reaguje. W kontaktach z ludźmi chodzi o zarządzanie, a dobrzy menedżerowie wiedzą, jak zmusić ludzi do reagowania.

Myślę, że pozytywne opinie są bardzo ważne i wynikają głównie z osobistej dynamiki realpolitik. Wszyscy siedzimy i piszemy kod godzinami, dniami, tygodniami, miesiącami i większość z nas jest dumna z tego, co robimy. Recenzje kodu są szansą, aby to pokazać.

Jeśli przejdziesz do przeglądu kodu, a najlepszym rezultatem, na który możesz liczyć, jest „brak komentarza” (tzn. Brak równowagi pozytywnych opinii), spotkanie można łatwo nazwać perspektywicznym „Dowiedz się, jak źle ludzie myślą, że ssiesz”. W rezultacie programiści zaczną się denerwować lub nawet przerażać recenzjami kodu, co wyraźnie szkodzi zespołowi. Programiści „zapomną” poddać przeglądowi kod lub rozwiną wyuczoną bezradność i po prostu zapytają swoich stałych krytyków, co zrobić z każdym drobiazgiem, aby uniknąć wybuchu na tych spotkaniach.

Dobrze jest powiedzieć, że teoretycznie najbardziej logiczne jest naprawienie zła i poproszenie wszystkich, aby zostawili emocje przy drzwiach, ale właśnie takie postawy odpowiedzialne za to, że programiści stają się głuche interpersonalnie. Pomijając teorie, jesteśmy ludźmi i ludzie od czasu do czasu lubią klepać się po plecach, nawet nominalnie. To się liczy.

Jest to ważniejsze, jeśli robisz recenzje towarzyszące lub zespoły. W pisemnej recenzji brak wiadomości to dobra wiadomość. Celem jest wprowadzenie kodu do produkcji. Kiedy jest to twój kod, powinieneś czuć się dobrze ze sobą.

Przegląd kodu powinien być wykorzystywany jako źródło informacji pomagających w mentorowaniu i zarządzaniu zespołem. Istnieje wiele okazji do wyrażenia pozytywnej opinii bez zaśmiecania bazy danych recenzji kodu. Przykłady można wyciągnąć, aby udostępnić je innym.

Recenzowanie programisty to coś więcej niż tylko jego kod. Czas sprawdzania kodu przechwytującego może przynieść efekt przeciwny do zamierzonego, gdy chcemy wyciągnąć aplikację z domu. Ustaw czas, który jest specyficzny, aby pomóc programistom poza recenzjami kodu, ale nie oznacza to, że powinieneś wykluczyć opinie z recenzji kodu.

Jedyny sposób, w jaki mogę wymyślić, gdzie pozytywne opinie na temat kodu mogłyby cię obrócić, to jeśli nie będziesz ostrożny, aby uniknąć „komplementu odręcznego”. Większość ludzi jest z tym zaznajomiona ... oznacza to zwrotami typu „Świetna robota, ale ...”

Jeśli wszyscy przyjdą na spotkanie z przekonaniem, że nie jest to osobisty przegląd programisty, ale próba ulepszenia praktyki kodowania dla jakości całego systemu, wówczas każda informacja zwrotna jest „dobra”. Informacje zwrotne, które podkreślają sposoby poprawy praktyki kodowania, stają się równie ważne, jak informacje zwrotne podkreślające nową przydatną metodę radzenia sobie z problemem.

Przynajmniej, jeśli ktoś nie podejmie takiej długości, należy podkreślić, że dążenie do wykonania cyklu „dobra opinia, zła opinia, dobra opinia, zła opinia” w ramach procesu przeglądu nastąpi tylko z to samo uczucie komplementu z ręki. Nie próbuj wymuszać dobrych informacji zwrotnych, staraj się wzmocnić dobry wysiłek i uzupełniać dziury w wiedzy.

Zwroty, z których nauczyłem się najwięcej przez lata:

• „To ciekawe podejście. Co się stanie, jeśli będziemy musieli uwzględnić [inny przypadek użycia]?”
• „Niezła próba! Czy wiesz, że mamy już taką metodę? Może powinniśmy przeprowadzić testy porównawcze, aby sprawdzić, które podejście jest bardziej wydajne”.

Przepływ pracy, który najbardziej podobał mi się w recenzjach kodu, był następujący:

1. Dev przesyła łatkę na listę mailingową / narzędzie online.
2. Każdy, kto musi się tym przejmować, patrzy na łatkę, sugeruje ulepszenia.
3. Dev wraca do # 1
4. Jeśli nie jest wymagana poprawa, ludzie mówią: „Dobra robota, proszę się zaangażować”. <- POZYTYWNE OPINIE. Cały akceptowany kod jest dobry. Im mniej ludzie muszą ci mówić, aby zmieniać rzeczy, tym lepiej sobie radzisz.
5. Dev zobowiązuje się, przechodzi do następnego elementu.

Zwykle zdarza się, że nowi deweloperzy otrzymują znacznie więcej „korekcyjnych” informacji zwrotnych, gdy zapoznają się z bazą kodu.

Korzyści z tego podejścia to:

1. Wszyscy wiedzą, co wszyscy robią. Nie ma wiedzy monopolizującej ani tajemniczych.
2. Każdy uczy się na podstawie opinii innych. To jest ważne. Jeśli informacje zwrotne zdarzają się tylko między 2 osobami podczas rozmowy twarzą w twarz podczas parowania, to osoba po drugiej stronie pokoju nie korzysta w taki sam sposób, jak gdyby to się stało na liście mailingowej.
3. Inni deweloperzy mogą zwykle wykryć błędy, zanim przejdą do kontroli wersji.

W ogóle się z tym nie zgadzam. Jaka jest różnica między Dobrymi Technikami Rozwoju a tak zwanymi Ninja Coders, którzy potrafią pisać niesamowity, ale niewytłumaczalny kod dla śmiertelników? Rozwój oprogramowania jest obecnie (IMO) dyscypliną o najniższym wspólnym mianowniku, w której unika się sprytu i sprytu na rzecz łatwości konserwacji i łatwości zrozumienia. To po prostu zbyt ryzykowne.

Nie mogę sobie wyobrazić czasu, w którym widziałem kod w recenzji, który sprawiłby, żebym powiedział „Och, to super”. Mogę tylko założyć, że gdybym napotkał taki kod, wpadłby do obozu Cool-Yet-Uncceptable.

Miałbyś również problemy z ludźmi, którzy nie otrzymali pozytywnej opinii, być może próbując zbyt mocno i ostatecznie robiąc bałagan „Zaufaj mi, to działa!”.

Przeglądy kodu służą rozłożeniu odpowiedzialności za jakość kodu na zespół, tzn. Indywidualnego programisty nie można obwiniać, jeśli później pojawi się poważny problem. Użyj go, aby znaleźć problemy, użyj go, aby uzyskać wyjaśnienia od oryginalnego twórcy dziwnych rzeczy na wypadek, gdybyś kiedyś musiał to utrzymywać. Osobiście jestem bardziej zainteresowany otrzymywaniem negatywnych opinii. Klienci nie dbają o fajność twojego kodu, tylko że robi to, czego chcą.

Pozostaw wsteczne uderzenie do pubu.

To miało dla mnie znaczenie. Nie chcę puchatych komentarzy ani pozytywności ze względu na pozytywność. Jeśli cały kod, który napisałem, jest kiepski, powiedz mi dlaczego, poprawmy go i nauczmy się. Ale jeśli zrobię coś dobrze, miło jest to usłyszeć raz na jakiś czas. Nie potrzebuję dodatniego wzmocnienia dla wszystkiego, co zrobiłem, to było „poprawne”, ale nawet jeśli jest to „poprawmy X, Y i Z, ale reszta wygląda dobrze”, to ma znaczenie.

Nie tak ważne jak uczciwe opinie. Pracuję dla dużej korporacji finansowej, a nasi klienci nie dbają o to, czy programista stara się, czy jest dobrym facetem, czy zwykle pisze dobry kod! Wymagają oprogramowania, które działa.

Myślę, że ważne jest, aby być całkowicie obiektywnym. Próba zwiększenia morale poprzez wyrażanie pozytywnych komentarzy jest dla mnie stratą czasu.

Może to oznaczać, że recenzje kodu są nadmiernie krytyczne - ale nie o to chodzi. Powinniśmy także być wobec siebie krytyczni. Uważam, że założenie, że kod, który napisałem, jest prawdopodobnie kompletnym śmieciem i zdecydowanie można go ulepszyć, popycha mnie do poprawy mojego kodu i poziomu umiejętności.

Jeśli nie otrzymasz żadnych komentarzy, możesz uznać, że wykonałeś dobrą robotę.

Mantra jest prosta: jeśli ktoś chce Kodeksu jakości (który w rzeczywistości jest mniej), należy zastosować odpowiednie metody przeglądu. Mimo to pozytywne opinie pomagają programistom / programistom myśleć i wymyślać pomysły / rozwiązania / poprawki. Nie bądź zbyt surowy, ale bądź stanowczy w kwestii. Pytania i odpowiedzi Menedżerowie powinni być świadomi dobrych metod i praktyk, aby mógł on / ona poprowadzić zespół (lub członka) we właściwym kierunku. Daje to jakość. Kropka.

Jeśli kod jest przeznaczony na konkurs lub jest przesłany na rozmowę kwalifikacyjną (innymi słowy, kod jest napisany i nie może być przepisany), pozytywne komentarze są koniecznością. W rzeczywistości powinieneś upewnić się, że są pozytywne opinie (tam, gdzie to możliwe!), A także negatywne. W ten sposób programista wie, gdzie leżą jego mocne i słabe strony, i może to zrekompensować.

Wydaje się jednak, że rozmawiasz w środowisku pracy, w którym kod można przepisać. W takim przypadku próbujesz usunąć błędy z twojego systemu. W tej sytuacji tylko negatywne błędy mają jakąkolwiek wartość.

Jeśli czujesz się nieswojo, zwołaj cotygodniowe spotkanie poświęcone przeglądowi kodu, na którym każdy może omówić zarówno dobry, jak i zły kod.

EDYCJA: Chociaż powiem, że jeśli coś robi na tobie wystarczające wrażenie, nic nie powstrzyma cię przed osobistym wyrażeniem uznania. Wygląda jednak na to, że moduł śledzący służy wyłącznie do przeglądu kodu produkcyjnego.