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 .