Jak radzić sobie z „prawie dobrym” kodem od młodszego programisty? [Zamknięte]

Mam pytanie dotyczące zarządzania zespołem. Obecnie mam do czynienia z młodszym programistą, który pracuje zdalnie z fabryki kodowania. Facet jest otwarty na krytykę i chętny do nauki, ale mam wątpliwości, jak bardzo powinienem popychać różne rzeczy.

Właśnie teraz, gdy coś jest proste i oczywiste, stanowi naruszenie dobrych praktyk: jak naruszenie SRP, obiektów Boga, nieistotnych nazw metod lub zmiennych; Wskazuję, co musi naprawić, i próbuję wyjaśnić, dlaczego to jest złe.

Moje pytanie brzmi: kiedy przestać? W tej chwili, jeśli wystąpią drobne naruszenia stylu kodowania, takie jak nazwy zmiennych w niewłaściwym języku (poprzedni zespół mieszał hiszpański i angielski i staram się to naprawić), lub drobne problemy strukturalne, pozwalam odejść i naprawić, jeśli Mam wolny czas lub potrzebuję zmodyfikować problematyczną klasę. Wydaje mi się, że jest to dobre dla morale zespołu, więc nie wypycham ciągle kodu, co dla nowicjusza może wydawać się drobnymi szczegółami, co może być dość frustrujące, ale martwię się również, że zbyt „miękki” może powstrzymać faceta od nauki, jak robić różne rzeczy.

Jak zrównoważyć granicę między nauczaniem faceta a nie wypalaniem go ciągłą krytyką? Dla młodszego może być frustrujące, jeśli powiesz mu, żeby powtórzył rzeczy, które działają na jego oczy.

Jeśli uważasz, że kod powinien zostać naprawiony przed scaleniem, zrób komentarz. Najlepiej z „dlaczego”, aby twórca mógł się uczyć.

Pamiętaj, że kod jest odczytywany znacznie częściej niż pisany. Rzeczy, które wydają się „niewielkie”, mogą być naprawdę ważne (na przykład nazwy zmiennych).

Jeśli jednak robisz komentarze, które wydają się nużące, może zastanów się:

• Czy Twój proces CI powinien je złapać?
• Czy masz czytelny „przewodnik dla programistów”, do którego możesz się odwoływać (czy też wszystko jest udokumentowane w twojej głowie)?
• Czy te komentarze rzeczywiście wpływają na jakość kodu?

Wiele osób poświęca produktywność na ołtarzu procesu lub doskonałości. Uważaj, aby tego nie zrobić.

Jeśli to możliwe, spróbuj osobiście odwiedzić kolegę. Lub użyj połączeń wideo. Budowanie relacji ułatwia zarządzanie krytyką (nawet recenzjami kodu).

Jeśli okaże się, że w kodzie występuje zbyt wiele błędów w przód / w tył, poproś o przejrzenie mniejszych fragmentów kodu. Zmiany przyrostowe prawdopodobnie unikną niektórych bardziej znaczących problemów projektowych, ponieważ są z definicji mniejsze.

Ale absolutnie nie łącz rzeczy, a następnie wróć i napraw je. Jest to pasywnie agresywne i jeśli deweloper stwierdzi, że to robisz, zabijesz ich morale.

Trzymaj krytykę kodu, a nie pisarza.

Każda wyprodukowana praca wiąże się z nieodłącznym przywiązaniem emocjonalnym. Zastanów się, jak to złagodzić, odsuwając kod od autora tak bardzo, jak to możliwe. Jakość kodu powinna być konsekwentnie ustalana jako wspólny cel, przed którym oboje stoicie razem, a nie jako punkt tarcia między wami.

Jednym ze sposobów osiągnięcia tego jest mądry wybór słów. Chociaż osoby ze STEM lubią uważać się za wysoce logiczne, emocje są częścią ludzkiej natury. Używany zwrot może być różnicą między zranionymi lub oszczędzonymi uczuciami. Powiedzenie „Ta nazwa funkcji byłaby bardziej spójna z konwencjami, gdyby była w języku angielskim”, jest lepsza niż „Napisałeś tę nazwę funkcji niepoprawnie i powinna być w języku angielskim”. Podczas gdy ten drugi jest nadal oswojony i sam wydaje się w porządku, w porównaniu do tego pierwszego jego wady stają się oczywiste - przygotowując, co powiedzieć albo osobiście, albo przez e-mail, sprawdź, czy twój kontekst, słowa i skupienie są na kwestiach, a nie osoba .

Język ciała

Chociaż słowa są ważne, większość komunikacji jest niewerbalna. Zwróć uwagę na mowę ciała, nawet pozornie nieznaczne subtelności, takie jak orientacja, np. Wiele interakcji między seniorami i młodszymi ma miejsce twarzą w twarz, ale podejście równoległe byłoby znacznie bardziej sprzyjające twojemu pożądanemu wynikowi.

Przekaż szczere pozytywne opinie

Wiele badań pokazuje, że informacje są przyswajane szybciej i lepiej przechowywane, gdy nagradzamy dobre zachowanie, a nie karanie złych. Czasami po prostu zauważam, że wydajność została poprawiona przez prostą „dobrą robotę” lub bardziej konkretną „Zauważyłem ostatnio, że twój styl dopasowuje nasze standardy do koszulki, świetna robota!” nawet uzupełnienie tego uznania za ulepszenie poprzez ich doradzenie komuś innemu w kwestiach, które poprawili, może mieć znaczenie dla twojego młodszego twórcy i jego pracy.

Facet jest otwarty na krytykę i chętny do nauki, ale mam wątpliwości, jak bardzo powinienem popychać różne rzeczy.

Wciśnij wszystko, co możesz. Jeśli facet się uczy, a Twoim zadaniem jest przejrzeć jego kod, oboje możesz wiele zyskać, jeśli wykona dobrą robotę.

Będzie to oznaczać mniej kodu do przejrzenia w przyszłości i może dać zespołowi docelowy poziom zatrudnienia.

Ponadto, jeśli powstrzymujesz się, nie pomagasz, ale protekcjonalnie.

Już sam fakt, że opublikowałeś tutaj swoje pytanie, pytając, czy robisz za dużo, już mnie sygnalizuje, że nie potrzebujesz tej konkretnej porady, ale dla innych, oto nadchodzi: pamiętaj, że naciskanie nie oznacza być palantem.

Bycie mentorem nie jest łatwym zadaniem. Będziesz także musiał dać mu trochę miejsca na samodzielne popełnianie błędów i poprawianie ich, po prostu upewnij się, że zrobi to w miejscu, które nie spowoduje prawdziwych obrażeń.

Opierając się na twoim opisie, zostawiłbym to w następujący sposób: „to dobrze. Jest kilka rzeczy, które zrobiłbym inaczej, ale nie są one bardzo ważne”.

Jak zdajesz się rozumieć, krytyka ma swoją cenę, a jeśli spędzasz dużo czasu na dręczeniu szczegółów, staje się to kwestią moralności. Idealnie wszystkie standardy kodowania są sprawdzane automatycznie i nie można budować, dopóki ich nie przestrzegamy. To ogromna oszczędność czasu i pozwala zabrać się do pracy. Jeśli zarezerwujesz swoją krytykę na „rzeczy, które mają znaczenie”, twoja rada będzie miała o wiele większy wpływ i będziesz postrzegany jako ceniony mentor. Bardzo ważne jest, aby odróżnić rzeczy, które nie są dobre, od rzeczy, które nie są dokładnie takie, jak byś to zrobił.

Wierzę w koncepcję możliwego do nauczenia momentu . Jeśli programista ma wystarczającą zdolność umysłową, może poprosić o szczegóły dotyczące tego, co zrobiłbyś inaczej. (S) może nie i to jest w porządku. Ludzie zostają wypaleni i na początku kariery może zająć dużo energii mentalnej, aby osiągnąć rzeczy, które później wydają się proste.

Rozważałbym zaakceptowanie jego pracy, gdy jest to dopuszczalne, a nie idealne. A następnie następnym zadaniem jest dyskusja, aby od razu ją przeredagować, wprowadzając wszystkie małe, ale ważne zmiany, które chcesz.

Kiedy więc praca jest po raz pierwszy akceptowana, twoja wiadomość jest taka, że ​​nie była zła, a niektóre miejsca zaakceptowałyby ją jako wystarczająco dobrą - ale nie miejsca, w których chciałbyś być jako młodszy programista, który chce właściwie nauczyć się swojego zawodu.

Więc nie mówisz: „Odrzucam twoją pracę, ponieważ nie jest wystarczająco dobra”. Mówisz (a) „Akceptuję twoją pracę, ponieważ jest wystarczająco dobra”, a następnie (b) „Ale chcę jej lepiej”.

Całkiem szeroko otwarte pytanie, ale oto kilka pomysłów.

1. Recenzje recenzentów (młodszego programisty)

   Najlepszym sposobem, aby ktoś nauczył się „właściwego” sposobu, jest zobaczenie, jak inni to robią. Czy wszyscy programiści wykonują recenzje kodu? Nie jest złym pomysłem, aby pozwolić młodszemu programistowi je wykonać (chociaż powinieneś również wymagać co najmniej jednej recenzji od starszego programisty). W ten sposób zobaczy dobrych koderów w akcji, a także zauważy, że komentarze recenzentów są skierowane do inżynierów innych niż on, co oznacza, że ​​nie jest to sprawa osobista.

2. Wczesne opinie / recenzje zadań

   Zezwól programistom na udział we własnym podziale zadań. Poproś go, aby zanotował swój zamierzony projekt w notatkach z zadania i przesłał „przegląd kodu” bez zestawu zmian i samego zadania. W ten sposób możesz przejrzeć jego plan, zanim napisze on jedną linię kodu. Po sprawdzeniu jego zadania może rozpocząć kodowanie (po czym prześle kolejną recenzję kodu). Pozwala to uniknąć demoralizującej sytuacji, w której programista napisał wiele rzeczy i musisz mu powiedzieć, żeby je przepisał.

Jeśli kod obiektywnie narusza zapisany, jednoznaczny standard, myślę, że powinieneś po prostu odpychać, aż każdy problem zostanie naprawiony. Oczywiście, może to być trochę denerwujące dla kilku pierwszych autorów, ale równie dobrze mogą poznać wytyczne wcześniej niż później.

Ponadto, jeśli dopuścisz kilka naruszeń standardów tu i tam, będą stanowić zły precedens - zobacz teorię rozbicia okien . O wiele łatwiej jest pamiętać o przestrzeganiu standardów, jeśli są one konsekwentnie stosowane w bazie kodu. Tak naprawdę wszyscy wygrywają, w tym młodsi programiści.

Nie sądzę, aby morale było dużym problemem, dopóki zapisany jest standard kodowania. Tylko wtedy, gdy staje się bardziej subiektywne „dobrze, ja zrobiłbym to inaczej” -territory, to powinieneś być zaniepokojony, ponieważ podejście deweloperów może być tak samo ważny.

Zastanów się nad przyjęciem procedury sprawdzania kodu, w której programiści publikują proponowane zatwierdzenia w narzędziu takim jak Github Pull Requests lub Phabricator Diffusion i otrzymują podpis rówieśniczy przed opublikowaniem swoich zmian we współdzielonej gałęzi głównej.

W ten sposób, zamiast z mocą wsteczną krytykować lub prosić kogoś o ponowne wykonanie tego, co już zostało zrobione, praca nie jest jeszcze wykonywana, dopóki nie przejdzie recenzji. W kółko z równorzędnymi elementami jest tak samo część procesu inżynierii oprogramowania, jak iz powrotem z kompilatorem.

Możesz publikować swoje obawy jako komentarze do poszczególnych linii i prowadzić wątkowe dyskusje na ich temat. On może zrobić to samo z twoim kodem. Dyskusja koncentruje się na konkretnych proponowanych zmianach kodu, a nie na czyichś wydajnościach lub kompetencjach w ogóle.

Nawet wspaniali starsi inżynierowie w mojej firmie są wdzięczni, gdy recenzje kodu łapią literówki lub zmuszają je do wyjaśnienia. Nowi pracownicy zatrudniają więcej rund iteracji. Z czasem zaczynasz odruchowo naprawiać problemy, o których wiesz, że przyciągają komentarze przed opublikowaniem pliku różnicowego. Uzyskanie wyższego odsetka zaakceptowanych różnic przy pierwszej próbie to sposób, w jaki wiesz, że się poprawiasz.

Nie odpycham ciągle kodu, co dla początkującego może wydawać się drobnymi szczegółami, co może być dość frustrujące, ale martwię się również, że zbyt „miękki” może uniemożliwić facetowi nauczenie się pewnych rzeczy.

Są to zarówno rzeczywiste możliwości, jak i uzasadnione obawy. Zapytaj programistę, co sądzi o tym.

Zakładając, że masz przepływ pracy związany z żądaniem ściągnięcia lub przeglądem kodu i wygląda na to, że tak, polecam zanotować rzeczy, które są „niekrytyczne” lub „preferowane”.

Jeśli widzisz PR w stanie podobnym do tego, co opisujesz, z pewnymi drobnymi problemami stylistycznymi lub wymagającymi niekrytycznego refaktoryzacji, zostaw komentarz, ale możesz też zaakceptować. Powiedzenie czegoś takiego: „W przyszłości spróbuj uniknąć takich nazw metod na rzecz czegoś takiego jak descriptiveMethodName” dokumentuje twoją opinię bez zmuszania ich do zmiany lub blokowania ich rozwoju.

Teraz znają twoje preferencje i jeśli próbują się poprawić, mam nadzieję, że zauważą taką sytuację w przyszłości. Pozostawia im także otwarte drzwi, aby faktycznie je zmieniali w tym czasie, jeśli zgodzą się z tobą i uznają to za wystarczająco krytyczne.

Mam do czynienia z młodszym programistą, który pracuje zdalnie z fabryki kodowania.

To niestety nie jest idealna sytuacja: jeden zaawansowany programista odpowiedzialny za jednego początkującego programistę, z separacją geograficzną. Nic dziwnego, że istnieje pewne napięcie, ale dysproporcję można złagodzić.

Jestem ciekawy, co rozumiesz przez „fabrykę kodującą”? Ta terminologia, moim zdaniem, wskazuje na niepokojące podejście, które może zaostrzać niektóre z wymienionych przez ciebie problemów zarządzania.

… Naruszenie SRP, obiektów Boga, nieistotnych nazw metod lub zmiennych; Wskazuję, co musi naprawić, i próbuję wyjaśnić, dlaczego to jest złe.

Myślę, że problem polega na tym, że twój młodszy programista wyrzuca kod, nie przechodząc przez odpowiedni proces projektowania. To z twojej strony, jako menedżera i starszego programisty, niedostarczenie wskazówek i nauczenie dobrych nawyków związanych z tworzeniem oprogramowania. Możesz przede wszystkim zapobiec pisaniu złego kodu, jeśli razem pracujesz nad szkicem konturu. Byłoby to lepsze niż krytykowanie i przepisywanie kodu po jego utworzeniu, zarówno pod względem wydajności, jak i morale.

Prawdopodobnie będziesz musiał dostosować przepływ pracy. Wygląda na to, że obecnie oczekujesz, że dostarczy ci produkty. Potrzebna jest ściślejsza współpraca, aby zapewnić wskazówki na każdym etapie rozwoju. Porozmawiaj o projekcie i interfejsie przed rozpoczęciem kodowania. Podczas kodowania rób częstsze punkty kontrolne, aby wcześniej wykryć problemy. Jeśli to możliwe, spróbuj sparować programowanie poprzez udostępnianie ekranu z kanałem audio.

Wszystko to będzie wymagać więcej wysiłku z twojej strony, ale prawdopodobnie będzie to opłacalne, biorąc pod uwagę problematyczne relacje, które obecnie masz.

Jeśli jest to naruszenie standardów kodowania, pokaż mu, gdzie to jest, aby wiedział. Jeśli musisz ciągle pokazywać mu ten sam błąd, możesz mieć problem z kimś, kto albo nie może przestrzegać zasad, albo odmawia. Nie marnuj wolnego czasu na naprawę błędów. Ta osoba powinna naprawić własne błędy, aby nie popełniać ich ponownie.

Zawsze mów im, co zrobili dobrze i jak mogą poprawić następnym razem. Zawsze możemy być lepsi w niektórych obszarach. Informacje zwrotne mają kluczowe znaczenie w poprawianiu czegokolwiek.

Innym pomysłem na radzenie sobie z „zbyt dużą krytyką” jest od czasu do czasu samodzielne wykonanie zadania i pozwolenie młodszemu programistowi na sprawdzenie kodu. Ma to co najmniej dwie zalety:

• mogą nauczyć się, jak należy to robić.
• w przypadkach, gdy istnieje wiele dobrych rozwiązań lub nazw zmiennych, akceptuję sugestie różnych, ale (prawie?) równie dobrych podejść. Kiedy naprawiam kod z powodu czyjegoś komentarza, pokazuję ludziom, że są szanowani, a krytyka zawsze dotyczy tylko kodu - bez względu na to, kto jest autorem.