Obecnie pracuję jako starszy programista z 3 młodszymi osobami pode mną i wprowadziłem proces sprawdzania kodu, aby pomóc w zarządzaniu jakością kodu wprowadzanego do produkcji.
Uważam, że dla nas wszystkich bardzo korzystne jest sprawdzanie siebie nawzajem, jednak po około 5 tygodniach procesu jestem jedynym, który może komentować narzędzie (BitBucket).
Myślę, że w pracy występują pewne problemy kulturowe i być może naturalna niechęć w przypadku, gdy ich komentarze są błędne, ale czy jest jakiś sposób i mogę pomóc młodym poczuć się bardziej komfortowo krytykując moje i nawzajem współpracując?
code-reviews
junior-programmer
mentor
Graham S.
źródło
źródło
Odpowiedzi:
Dla mnie pytanie brzmi: „Czego szukasz swoich młodszych programistów, aby wydostać się z recenzji kodu?”. Dla mnie potencjalnie najważniejszą rzeczą jest, aby młodsi programiści uczyli się, patrząc na, co, mam nadzieję, dobry kod; jeśli zdołają znaleźć problemy w twoim kodzie, to bonus.
Jeśli szukasz młodszego personelu do nauki na podstawie recenzji kodu, najważniejszą rzeczą, którą musisz zrobić, to stworzyć środowisko, w którym nauka jest ceniona, a nie postrzegana jako strata czasu. Oznacza to wiele rzeczy:
źródło
Co tydzień organizuj spotkania poświęcone przeglądowi kodu o określonej godzinie. Sprzedałem to mojemu koledze z drużyny w ten sposób (tak naprawdę oboje jesteśmy starszymi deweloperami, ale cokolwiek):
„Przegląd kodu jest częściowo po to, abym mógł lepiej poznać Twój kod i dowiedzieć się, co dzieje się po twojej stronie, na wypadek, gdybyś kiedyś został potrącony przez ciężarówkę i kazano mi zakończyć twój sprint. Ale głównie abyś wyjaśnił swój kod komuś innemu, ponieważ kiedy to robisz, angażuje on inną część twojego mózgu, i często razy jego wyjaśnienie i / lub ich pytania lub komentarze mogą spowodować, że pamiętasz coś, o czym zapomniałeś zrobić w kodzie, lub może sprawić, że zrozumiesz lepszy sposób, aby uczynić go bardziej czytelnym lub lepiej go zaprojektować. To prowadzi do piękniejszego kodu ”.
Lubię myśleć o tym jak o show-and-tell. Ludzie mogą pochwalić się swoją pracą swoim rówieśnikom. Nie chodzi o to, aby twoi rówieśnicy znaleźli coś złego w pracy, czego nikt nie lubi. Chodzi o to, aby zaimponować swoim rówieśnikom niesamowitym kodem, który wszyscy lubią.
Jednak myślę, że używanie narzędzi do przeglądania kodu, w których nie ma interakcji człowieka, nie ma spotkania w pokoju, nie ma tablicy ... staje się to po prostu kolejną irytującą „rzeczą” do zrobienia. Nie jest tak, że nie powinny istnieć takie narzędzia, ale powinny one być czymś, na co należy się zwrócić, jeśli podczas spotkania poświęconego przeglądowi kodu zdamy sobie sprawę, że niezbędna może być bardziej szczegółowa analiza pewnej sekcji kodu. Następnie możesz przypisać jednego z młodszych programistów do przejrzenia kodu drugiego w określonym obszarze.
źródło
Możesz pomóc, dając dobry przykład. Nie możesz się obronić, gdy ktoś wskaże twoje błędy. Dokonaj przeglądu kodu na własnym kodzie i zanotuj obszary wymagające poprawy. Udostępnij to zespołowi. W końcu dowiedzą się, że jest to zalecane i nikt nie dostanie bicia za błąd w kodzie.
Posiadanie pracy oznacza wzięcie odpowiedzialności i dumy z pracy. Jeśli przegląd kodu jest częścią tego, udział w przeglądzie kodu powinien być uwzględniony w ocenach. Brałem udział w zajęciach online, w których udział w dyskusjach online jest częścią oceny. Należy opracować komentarze. „Zgadzam się” jest niedopuszczalne.
Przegląd kodu powinien poprawić kod. W zależności od sytuacji można to zmierzyć na podstawie numerów sprzedaży, skarg użytkowników lub innych ocen, jeśli piszesz kod do użytku wewnętrznego. Rzeczywistość jest taka, że twój kod ma jakiś cel i twój zespół powinien być mierzony na podstawie tego, jak dobrze służą temu celowi. Ci, których określisz, przyczyniają się do sukcesu, dzielą się proporcjonalnie w nagrodach.
Skoncentruj się na wydaniu kodu jakości. Celem nie jest, aby wszyscy czuli się dobrze, unikając błędów. Piszę zły kod; Muszę naprawić zły kod. To jest praca i życie. Nienawidzę naprawiać błędów, więc staram się ich unikać. Jestem dumny z mojej pracy, więc przeszkadza mi, gdy mój kod nie działa. Żal mi użytkowników lub innych osób, które muszą poświęcić swój czas na wskazanie tych rzeczy i motywuje mnie to do naprawy.
Na marginesie, jeśli masz środowisko, w którym nikt nie może wyrażać ani przyjmować konstruktywnej krytyki, masz problem.
źródło
Proces: ktoś chce zatwierdzić swoje zmiany. Ktoś jest wyznaczony jako recenzent i przegląda zmiany. Następnie sprawdzone i naprawione zmiany przechodzą do testowania.
Jeśli testy wykryją błędy wprowadzone w tej zmianie, to autor i recenzent są w równym stopniu winni.
Więc dokonanie recenzji bez żadnych komentarzy sprawi ci kłopoty, chyba że kod będzie doskonały.
źródło