Jak wziąć odpowiedzialność za kod, gdy kolega wprowadza niepotrzebne poprawki bez uprzedzenia?

Jeden z moich kolegów z zespołu jest specjalistą od wszystkich transakcji w naszym sklepie IT i szanuję jego wgląd.

Czasami jednak przegląda mój kod (jest szefem naszego zespołu, więc się tego spodziewałem) bez uprzedzeń. Czasami więc przegląda moje zmiany, zanim osiągną cel końcowy i wprowadzają zmiany od razu ... a nawet raz złamał moją pracę.

Innym razem wprowadził niepotrzebne poprawki do mojego kodu, który ma ponad 3 miesiące.

Denerwuje mnie to z kilku powodów:

1. Nie zawsze mam szansę naprawić swoje błędy
2. Nie poświęcił czasu, by zapytać mnie, co próbowałem osiągnąć, gdy jest zdezorientowany, co może wpłynąć na jego testy lub zmiany
3. Nie zawsze uważam, że jego kod jest czytelny
4. Terminy nie stanowią problemu, a jego bieżące obciążenie pracą nie wymaga żadnej pracy w moich projektach poza przeglądaniem zmian w kodzie.

W każdym razie, powiedziałem mu w przeszłości, żeby informował mnie na bieżąco, jeśli zobaczy w mojej pracy coś, co chce zmienić, abym mógł przejąć na własność mój kod (być może powinienem powiedzieć „niedociągnięcia”) i nie reaguje .

Obawiam się, że mogę odejść równie agresywnie, gdy poproszę go o wyjaśnienie mi swoich zmian.

Jest tylko cichą osobą, która trzyma się dla siebie, ale jego działania trwają. Nie chcę go wypędzać z dokonywania zmian w kodzie (nie jakbym mógł), ponieważ jesteśmy zespołem - ale chcę zrobić wszystko, aby pomóc naszemu zespołowi.

Dodano wyjaśnienia:

• Dzielimy 1 dział rozwoju. Nie czekam, aż wszystkie moje zmiany zakończą jedno zadanie, ponieważ ryzykuję utratę znaczącej pracy - więc upewniam się, że moje zmiany się kompilują i niczego nie psują.
• Obawiam się, że mój kolega z zespołu nie wyjaśnia przyczyny ani celu jego zmian. Nie sądzę, żeby potrzebował mojego błogosławieństwa, ale jeśli nie zgadzamy się co do podejścia, pomyślałem, że najlepiej będzie omówić zalety i wady i podjąć decyzję, gdy oboje zrozumiemy, co się dzieje.
• Nie rozmawiałem o tym jeszcze z kierownictwem naszego zespołu, ponieważ wolałbym rozwiązywać osobiste spory bez angażowania kierownictwa, chyba że jest to konieczne. Ponieważ moja troska wydawała się bardziej kwestią osobistą niż zagrożeniem dla naszej pracy, postanowiłem nie niepokoić kierownictwa zespołu. Pracuję nad pomysłami na proces recenzji kodu - aby pomóc promować korzyści z bardziej zorganizowanych recenzji kodu bez zajmowania się moimi ulubieńcami.

Myślę, że większość programistów znajduje się w takiej sytuacji w pewnym momencie i mam nadzieję, że każdy programista, który poczuł się ofiarą, zdaje sobie sprawę, jak frustrujące będzie, gdy stanie się starszy i poczuje się zmuszony do czyszczenia kodu napisanego przez juniorów.

Dla mnie unikanie konfliktu w tej sytuacji sprowadza się do dwóch rzeczy:

1. Dzięki uprzejmości . Rozmowa z kimś o jego / jej kodzie pozwala deweloperowi wiedzieć, że jesteś zainteresowany i możesz omówić go jako dorośli profesjonaliści.

2. Zapomnij o „posiadaniu kodu” - zespół jest właścicielem kodu . Inni ludzie, którzy chcą wprowadzić zmiany, to dobra rzecz. Jeśli starszy programista wprowadza zmiany, które są „nieczytelne” lub gorsze, wycofaj je. Nie musisz być agresywny, po prostu daj redaktorowi znać, że jego / jej zmiany nie zadziałały i chętnie porozmawiasz o swoim powrocie.

Pamiętaj, własność kodu w zespole jest świetna i tnie na dwa sposoby. Jeśli widzisz coś, co nie ma sensu w czyimś kodzie, napraw to. Bycie nadmiernie zaborczym i niedostatecznie komunikatywnym to pewny sposób na stworzenie trującego środowiska programistycznego.

Ty i większość osób udzielających odpowiedzi traktujecie to jako kwestię komunikacji między dwoma kolegami, ale tak naprawdę nie sądzę. To, co opisujesz, przypomina bardziej okropnie zepsuty proces sprawdzania kodu niż cokolwiek innego.

Po pierwsze, wspominasz, że twój kolega jest drugim dowódcą i oczekuje się, że sprawdzi twój kod. Po prostu źle. Z definicji przeglądy kodów równorzędnych nie są hierarchiczne i na pewno nie polegają wyłącznie na znajdowaniu defektów. Mogą również zapewnić doświadczenia edukacyjne (dla wszystkich zaangażowanych), okazję do interakcji społecznych i okazać się cennym narzędziem do budowania własności kodu zbiorowego. Powinieneś także od czasu do czasu sprawdzać jego kod, uczyć się od niego i poprawiać go, gdy się myli (za każdym razem nikt go nie poprawia ).

Ponadto wspominasz, że twój kolega wprowadza zmiany od razu. To również źle, ale oczywiście już to wiesz; nie zadałbyś tego pytania, gdyby jego podejście nie było problemem. Myślę jednak, że szukasz rozwiązania w niewłaściwym miejscu. Szczerze mówiąc, twój kolega przypomina mi trochę ... mnie, a tym, co działało dla mnie w podobnych sytuacjach, był dobrze zdefiniowany i solidny proces recenzji oraz zestaw niesamowitych narzędzi. Naprawdę nie chcesz powstrzymywać swojego kolegi od sprawdzania twojego kodu i proszenia go, aby przestał i rozmawiał z tobą, zanim każda drobna zmiana tak naprawdę nie zadziała. Może to chwilę potrwać, ale wkrótce osiągnie punkt, w którym stanie się to zbyt denerwujące, a ty wrócisz tam, gdzie zacząłeś, albo gorzej: po prostu przestanie sprawdzać twój kod.

Kluczem do rozwiązania tutaj może być narzędzie do przeglądu kodu równorzędnego. Zwykle unikam rekomendacji produktów, ale w przypadku recenzji kodu Atlassian's Cruciblenaprawdę ratuje życie. To, co robi, może wydawać się bardzo proste i tak jest, ale to nie znaczy, że nie jest niesamowicie niesamowite. Łączy się z Twoim repozytorium i umożliwia przeglądanie poszczególnych zestawów zmian, plików lub grup plików. Nie możesz zmienić żadnego kodu, zamiast tego komentujesz wszystko, co nie jest w porządku. A jeśli absolutnie musisz zmienić kod innej osoby, możesz po prostu zostawić komentarz z zestawem zmian wyjaśniającym twoje zmiany. Film wprowadzający na stronie produktu Crucible jest wart obejrzenia, jeśli chcesz uzyskać więcej szczegółów. Ceny Crucible nie są dla wszystkich, ale istnieje wiele darmowo dostępnych narzędzi do wzajemnej oceny. Jedną z nich, z którą pracowałem i która mi się podobała, jest komisja rewizyjna i jestem pewien, że znajdziesz wiele innych dzięki prostej wyszukiwarce Google.

Niezależnie od wybranego narzędzia, całkowicie zmieni Twój proces. Nie musisz się zatrzymywać, wstać z krzesła, przerwać drugiej osobie i omówić zmiany; wszystko co musisz zrobić, to zrobić sobie przerwę co tydzień i przejrzeć komentarze (raz w tygodniu to tylko sugestia. Znasz swój harmonogram i codzienną rutynę lepiej niż ja). Co ważniejsze, podstawowe recenzje są przechowywane gdzieś w bazie danych i można je odzyskać w dowolnym momencie. Nie są to efemeryczne dyskusje wokół chłodnicy wody. Moim ulubionym przypadkiem użycia starych recenzji jest wprowadzenie nowego członka zespołu do naszej bazy kodów. Zawsze jest miło, gdy mogę wprowadzić kogoś nowego przez bazę kodów, wskazując, gdzie dokładnie utknęliśmy, gdzie mieliśmy różne opinie itp.

Przechodząc dalej, wspominasz, że nie zawsze można odczytać kod tego kolegi. To pozwala mi wiedzieć, że nie masz wspólnego zestawu standardów kodowania, a to źle. Ponownie możesz podejść do tego jako problemu ludzi lub możesz podejść do tego jako problemu procesowego, i ponownie zdecydowanie sugeruję to drugie. Zbierz zespół i jak najszybciej zastosuj wspólny styl kodowania i zestaw standardów. Tak naprawdę nie ma znaczenia, czy wybierzesz zestaw standardów, które są wspólne dla ekosystemu rozwoju, czy sam wymyślisz własne. To, co naprawdę się liczy, to spójność standardów i ich przestrzeganie. Wiele narzędzi może ci pomóc, ale to zupełnie inna dyskusja. Na początek, bardzo prostą rzeczą jest posiadanie haka przed zatwierdzeniem, który uruchamia w twoim kodzie jakiś formatator stylu. Możesz kontynuować pisanie kodu w dowolny sposób i pozwolić narzędziu „naprawić” automatycznie, zanim ktokolwiek go zobaczy.

Na koniec wspominasz w komentarzu, że kierownictwo nie uważa, aby poszczególne oddziały programistów były konieczne. Istnieje powód, dla którego nazywamy je „gałęziami deweloperów”, a nie „gałęziami zarządzania”. Zatrzymam się tutaj, ponieważ nie ma powodu, aby rant, który formuje się w mojej głowie, miał się wydostać.

Wszystko, co powiedziałem, wiedz, że nie wątpię, że twój kolega jest (trochę) winny tutaj. Nie o to mi chodzi, chodzi mi o to, że cały twój proces rozwoju jest również winny, i to jest coś, co jest łatwiejsze do naprawienia. Uzbrój się w odpowiednie narzędzia, poznaj liczne formalne i nieformalne procesy i wybierz te, które pasują do Twojego zespołu. Wkrótce osiągniesz punkt, w którym zdasz sobie sprawę, że większość twoich „problemów z ludźmi” już nie istnieje. I proszę, nie słuchaj nikogo (w tym siebie), który przedstawia „jesteśmy małym zespołem, nie potrzebujemy tego wszystkiego”. Zespół kompetentnych programistów może skonfigurować niezbędne narzędzia w niecały tydzień, zautomatyzować wszystko, co można zautomatyzować, i nigdy nie oglądać się za siebie.

PS. „Własność kodu” jest mglistym terminem, stale dyskutowanym i oznacza różne rzeczy dla różnych ludzi. Możesz znaleźć genialny zbiór większości różnych (a czasem antytezycznych) opinii na temat C2 .

Co takiego jest w procesie, który sprawia, że ​​chcesz wziąć odpowiedzialność za „swój kod”? Czy ponosisz wyłączną odpowiedzialność za działanie niektórych funkcji? Czy szef powiedział „Michael, chcę, żebyś wziął odpowiedzialność za ...”? A może Twoja odpowiedzialność wynika domyślnie z tego, że kierownictwo i reszta zespołu patrzą na ciebie za każdym razem, gdy niektóre funkcje są zepsute?

Tak czy inaczej, jeśli ponosisz odpowiedzialność, potrzebujesz autorytetu nad kodem. Następnym razem, gdy drugi dokona jednostronnych zmian, a trop powróci do ciebie, aby je naprawić, powinieneś usiąść z tropem i poprosić o wyrównanie swoich uprawnień i odpowiedzialności.

Nie to rozwiąże całą sytuację, ale możesz spróbować dodać więcej komentarzy do swojego kodu źródłowego.

1. Jeśli kod nie jest kompletny, może zostać oznaczony jako taki.
2. Jeśli celem bloku kodu nie jest samo-dokumentowanie, powinieneś to udokumentować.

W sumie staraj się, aby lemoniada zamiast marnować czas na ssanie cytryn. Jak powiedział Michael, koledzy z drużyny nie robią nic, aby wyglądać źle. Spróbuj uczyć się na swoich błędach i zastosować je w przyszłych wersjach.

Jeśli uważasz, że jego zmiany mają negatywny wpływ, wypowiedz to (dyplomatycznie). Gdybym to był ja, po prostu zapytałbym, dlaczego dokonano określonych zmian i sprawdziłbym, czy możesz obronić swoje oryginalne zmiany. Twoi starsi współpracownicy są również ludźmi. Jest całkiem możliwe, że coś przeoczył i / lub nie jest świadomy żadnego negatywnego wpływu, jaki wywiera.

Każdy domyślnie „posiada swój własny kod”, niezależnie od polityki, legalizmu lub ekonomii - jest to „natura rzeczy” - naturalnie odczuwasz osobisty związek ze swoją pracą.

Jeśli twój współpracownik angażuje się w zachowanie, które opisałeś i nie reaguje, gdy poprosisz o awans , ten współpracownik jest co najmniej nieuprzejmy i może próbować cię osłabić (mówiąc najgorzej ... .) - NIE brzmi jak gracz zespołowy.

Dobry współpracownik będzie dotykać podstawy z wami i wskazać na problem z kodem do ciebie - i niech to naprawić / zmienić go lub odpowiednio reagować. Jestem bardzo wdzięczny, że nawet gdy byłem nowicjuszem, moi mentorzy zawsze wskazywali mi, co robię źle, wyjaśniali dlaczego i pozwalali mi (lub zmuszali ) to naprawić. To uczyniło mnie lepszym programistą i wszyscy na tym skorzystali. I to zawsze robiłem, kiedy przeglądałem pracę wykonaną przez innych. Wtedy ty (lub ktokolwiek) faktycznie uczy się czegoś od twojego „waleta wszystkich zawodów”, a kod i zespół stają się coraz lepsi, w tym twój nauczyciel: Nauczanie pomaga zrozumieć.

Jeśli to w ogóle możliwe, porozmawiam o tym na osobności z kierownikiem zespołu. Opierając się na twoim opisie sytuacji, dobry lider zespołu weźmie twoją stronę - zły nie zrobi tego ... Oczywiście wymaga to ostrożności - musisz to ocenić sam.

Jeśli piszesz kod, powinienem go przejrzeć.

Jeśli zmienię kod podczas sprawdzania, kod nie jest już kodem, który sprawdziłem, ale kod, który zmieniłem. Dlatego należy to zweryfikować. Prawdopodobnie przez ciebie.

Jeśli zatwierdzę twój nowy kod wraz z moimi zmianami, a ktoś nie sprawdzi moich zmian, to popełniłem (1) nie sprawdzoną zmianę i (2) najgorszy możliwy grzech, jeśli recenzje kodu są traktowane poważnie.

Myślę, że na razie radzisz sobie z tym we właściwy sposób - ale wkrótce pojawi się punkt zwrotny, który rozproszy Cię w stopniu, w którym możesz nie być zadowolony z pisania w ten sposób.

Gdybym był tobą, poprosiłbym o szybką rozmowę indywidualną z tą osobą i wyjaśniłbym mój POV spokojnie, ale stanowczo. Własność zespołu w zakresie kodu itp. Jest w porządku, ale chyba że dasz każdemu programistowi wystarczająco dużo miejsca, aby mógł on rozpracować swoją pracę, popełniać błędy i ulepszać, nigdy nie zbudujesz dobrego kodu. Może to być obszar tarcia wcześniej niż później.

(Odpowiedź jest zupełnie inna, jeśli dotyczy to wymiany pracy. Wymiana stosów. Łatwo jest znaleźć właściwy sposób na przeglądanie kodu. Przekonanie współpracownika do przestrzegania tego jest znacznie trudniejsze).