Jak powinienem zająć się naprawą kodu od mniej doświadczonego programisty?

Trochę tła: jestem jednym z dwóch programistów dla naszego działu 10 osób (reszta to artyści i kierownictwo). Oboje wykonujemy wszystkie kodowania wymagane do poprawnego przepływu i opracowujemy wszelkie projekty, które się pojawią. Programuję od około 4 lat, gdzie jest to jego pierwsza „prawdziwa” praca (jak to ujął). Generalnie pracujemy nad różnymi projektami w dowolnym momencie.

Kilka miesięcy temu opracowałem (wcale nie idealny) zestaw klas, które miały być wykorzystane w późniejszym projekcie. Duża część tego projektu została mu przekazana (ze względu na faktury) do zaprojektowania i zaprogramowania interfejsu GUI. Ponieważ był nowy, pomogłem trochę przy projektowaniu i powiedziałem, aby poprosić o pomoc, jeśli będzie potrzebował jej z resztą. Interfejs skończył kilka tygodni temu, który pokazał, że działa, choć trochę wolno.

Rozpoczęła się kolejna część tego projektu, nad którą pracuję. Otworzyłem interfejs, aby zacząć od kolejnych kroków, i od razu natknąłem się na problemy (trochę powolne było trochę niedopowiedzenia, błędy w typowych działaniach itp.). Zajrzałem do kodu w celu znalezienia kilku problemów i znajduję O(n^n)na wywołaniach, które powinny O(n), wpisz założenia bez sprawdzania błędów (jest w Pythonie), odniesienia do GUI dodane do oryginalnego kodu i tak dalej.

Teraz zdecydowanie chciałbym nauczyć go, co jest nie tak i jak to naprawić, ale już przeszedł do następnego projektu, a było to kilka tygodni temu. Obawiam się, że mówię: „Wróć i zrób to dobrze!” (z pomocą oczywiście) jest zbyt trudny, a tymczasem wciąż mamy inne projekty do wykonania. Czy powinienem po prostu sam naprawić kod i spróbować złapać coś w przyszłości?

Wygląda na to, że ustanowienie zasad przeglądu kodu może być korzystne na wielu poziomach. Niektóre natychmiastowe korzyści:

• Możesz bezpośrednio wpływać na jakość jego kodu przed zatwierdzeniem kodu, utrzymując wysoką jakość bazy kodu
• Zapobiega popełnianiu podobnych błędów, które mogą złapać inny zestaw oczu
• W przypadku braku wytycznych dotyczących kodowania recenzje naturalnie prowadzą do spójności stylu kodowania
• Dzielenie się wiedzą. Jeśli jest tylko dwóch z was, a jeden zostaje potrącony przez autobus ...

Teraz, kiedy zaczniesz czyścić jego kod, użyj go jako ćwiczenia dydaktycznego, gdy będziesz chciał przejrzeć ten kod. Będziesz sprawdzać swoje rzeczy, a on może nauczyć się robić to lepiej następnym razem.

Nigdy nigdy nie naprawiaj swojego kodu, w przeciwnym razie nie nauczą się niczego innego, niż jeśli popełni błędy, złapiesz je i naprawisz. Zadanie nie zostanie wykonane, dopóki nie zostanie wykonane . Miałem naprawdę szczęście, kiedy zacząłem profesjonalnie, a mój bezpośredni przełożony ponownie sprawdził wszystko, co popełniłem, a jeśli byłoby lepsze rozwiązanie lub popełniłem głupi błąd, powiedziałoby mi to, co oznaczało, że moje umiejętności się poprawiły, co oznaczało, że poprawiłem się szybciej i rozwinąłem twardsza skóra.

Pozwolenie na ześlizgnięcie się wyhoduje złe nawyki, poprawienie teraz sprawi, że lepiej poradzą sobie z krytyką i potroją się, zanim potwierdzisz, że to zrobione.

Czy możemy wywnioskować, że projekt „działa” i został wykonany w rozsądnym czasie (choć z pewnymi poważnymi, ale możliwymi do naprawienia problemami projektowymi)? Jeśli tak, jest w lepszej formie niż wiele projektów, które widziałem przez lata.

Myślę, że większa komunikacja pomogłaby Twojemu zespołowi - i można to zrobić poprzez regularne sprawdzanie kodu.

Dobrze, że jesteś wrażliwy na to, że jesteś „zbyt surowy” i myślę, że pamiętasz o tym, że przegląd kodu nie musi być demoralizującym doświadczeniem, gdy młodsi ludzie są grillowani i analizowani. Może to być również sposób dla starszych programistów na wykazanie się dobrymi praktykami i na zdobycie wzajemnego zaufania poprzez uprzejmość i przyjazność nawet w przypadku „błędów”.

Ludzie uczą się dobrze, kiedy widzą, jak naprawdę wyglądają dobre rzeczy. Jest to lepsze niż systematyczne wskazywanie każdej małej wady. O (n ^ n) należy jednak delikatnie i konstruktywnie wskazać.

Podziel się swoją wiedzą.

Oferowałbym mu pomoc w jego nowym projekcie w zamian za nauczanie od seniora do juniora.

Dlaczego nie sparować programowania w obu projektach?