Jak zachęcić młodszych programistów do udziału w przeglądzie kodu?

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?

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:

• Nie ma czegoś takiego jak głupie pytanie . Jeśli ktoś nie rozumie odrobiny kodu, dlaczego użyłeś określonego wzorca lub cokolwiek innego, musi swobodnie zapytać, nigdy nie zmuszając się do poczucia, że ​​marnuje on twój czas lub czas innych programistów .
• Czas spędzony na nauce to czas dobrze spędzony . Chcesz, aby twoi młodsi programiści spędzali czas na szukaniu kodu i uczeniu się z niego, ponieważ dzięki temu będą lepsi, bardziej produktywni pracownicy w przyszłości. O ile nie jest to krytyczna poprawka, którą należy teraz przejrzeć , zachęć ich do poświęcania więcej, a nie mniej czasu na przeglądy kodu.
• Wyżsi pracownicy nie zawsze mają rację . To, że robisz to dłużej, nie oznacza, że ​​masz rację. Jeśli myślą, że znaleźli błąd, prawdopodobnie mają rację. Jeśli uważają, że odpowiedni wzorzec projektowy byłby odpowiedni dla tego fragmentu kodu, muszą swobodnie to powiedzieć, nie otrzymując negatywnej opinii.

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.

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.

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.