Mógłby mieć rację, że kod wymaga naprawy, ale robi to w niewłaściwy sposób podczas każdej weryfikacji kodu, jaką kiedykolwiek widziałem. Przeglądy kodu powinny zakończyć się niepowodzeniem w przypadku bardzo konkretnych, adresowalnych punktów, np .:

1. Niespójne wcięcia w ScoreHandler.cpp, wiersze 45-50. Narusza wytyczne stylu nr 8.
2. getConsistentReview () w Foo.java nie jest bezpieczny wątkowo, zgodnie z wymaganiami, synchronizacja na niewłaściwym zamku.
3. getFoo () w Foo.java wykonuje iterację po liście, aby odfiltrować wyniki. Ponieważ nasz poziom źródła wynosi teraz 8, zamiast tego do filtrowania powinno używać się API strumienia, co jest znacznie bardziej zwięzłe.

Wygląda na to, że masz kogoś, kto (źle) próbuje mentorować zmuszając Cię do „naprawy” kodu w sposób, w jaki chce, bez wyjaśniania Ci dokładnie, dlaczego jest uszkodzony lub co jest z nim nie tak. Nie jest nawet jasne, czy powód, dla którego chce, abyś ją zmienił, jest stylistyczny czy funkcjonalny.

Możesz po prostu odmówić gry w piłkę i odepchnąć ją z powrotem. Czy uważasz, że to zadziała ogólnie, czy spowoduje więcej problemów, zależy od kultury.

Jeśli chcesz bardziej miękkiego podejścia, spróbuj opisać bardziej szczegółowo, czego próbowałeś, dlaczego tak się nie stało. t działa i podaj dokładnie, co musisz kontynuować:

Cześć x,

Wcześniej próbowałem usunąć kod y , jak sugerowałeś , ale to zamiast tego powoduje wystąpienie z , co powoduje niepowodzenie (tych) testów funkcji w (tych) przypadkach. Nie mam jasności co do tego wymagania - czy zmiana, o którą prosisz, ma być stylistyczna czy funkcjonalna? Jeśli jest to stylistyczne, czy mógłbyś wskazać konkretne wytyczne dotyczące stylu, które kod narusza, a jeśli jest funkcjonalny, czy możesz podać mi przypadek testowy, który się nie udaje?

Żadne z powyższych nie jest nierozsądne poproś o sprawdzenie kodu - bardziej nierozsądne jest to, że nie został dostarczony na początku.

Jeśli po tym nadal mówi „po prostu zrób to, co próbowałem”, możesz po prostu cofnąć się za pomocą „Jak powyżej, obawiam się, że to nie zadziałało i potrzebuję znacznie więcej szczegółów, aby rozwiązać problem problem." Jeśli ktoś zajdzie na ciebie przez długi czas, pokaż mu ślad papieru; powinno dość szybko stać się jasne, że to on ciągnie nogi i nie chce grać w piłkę.

Jeśli chodzi o przepływ pracy w mojej firmie, byłoby to łatwe.

Oznacz żądanie zmiany jako „nie będzie naprawiać” z komentarzem „poprawna poprawka odrzucona przez recenzenta”, a następnie przypisz mu tę prośbę. Oczywiście wie, jak to naprawić, więc powinno to zająć mu pięć minut.

I właściwie, jeśli miał rację, to byłoby to właściwe. Nie ma sensu tracić czasu. Nie ma więc na co narzekać.

W przypadku starego i niejasnego kodu mogą się zdarzyć dwie rzeczy: zostawiam go bez zmian lub ulepszam go i biorę na siebie odpowiedzialność, jeśli się zepsuje. Jedyną rzeczą, która nie się stanie, jest to, że polecam komuś innemu wprowadzenie tych zmian. A już na pewno nie podczas przeglądu kodu.

Może to nie dotyczyć Ciebie z przyczyn technicznych lub organizacyjnych, ale ogólna odpowiedź brzmi:

Wykonaj test jednostkowy

Test jednostkowy jest dowodem na to, że błąd został naprawiony. Za każdym razem, gdy naprawiasz błąd lub za każdym razem, gdy musisz zademonstrować błąd, testowanie jednostkowe oszczędza wiele argumentów. Sprawdź, czy jest osoba odpowiedzialna za kontrolę jakości, z którą możesz porozmawiać i rozwiązać ten problem.

Pamiętaj, że nie odrzucił Twojej zmiany, ponieważ nie zadziałała, odrzucił ją, ponieważ nie była jego zmiana. Poparcie testu jednostkowego wzmacnia Twoją pozycję.

Szczególnie w Twojej sytuacji: pamiętaj, że jeśli on chce, abyś zrobił to, co powiedział, powinien zrobić to sam. To twoje zadanie i możesz robić to, co ty powiesz. Taka jest Twoja mentalność, teraz do dialogu.

Zadzwoń do programisty i porozmawiaj z nim. Pokaż, że twoja poprawka działa, a jeśli zostaniesz zapytany, dlaczego nie zrobiłeś tego, co powiedział, możesz powiedzieć coś takiego:

To nie jest dokładnie to, co powiedziałeś, ale działa i naprawia problem. Rozumiem to rozwiązanie w mojej głowie, inny sposób prawdopodobnie też by działał, ale zajęłoby mi dużo więcej czasu, aby się zorientować. Więc myślę, że możemy oznaczyć ten jako zaliczony w przeglądzie kodu?

Zgadzam się z berry120. Jednak Twoje notatki z recenzji były

„to nie zadziała, zmieniłeś zły kod” i „nie zrobiłeś tego, co powiedziałem”

Moja sugestia:

(Poświęć na to nie więcej niż pół dnia. Dokładnie udokumentuj odpowiednie zachowanie kodu, błędy / ostrzeżenia, podjęte działania i powody ich podjęcia tak.)

• upewnij się, że nowy kod działa w wersji X (bez błędów i ostrzeżeń) zgodnie z żądaniem klienta.
• utwórz rozwidlenie lub wersję kod przed zmianami
• postępuj dokładnie tak, jak w notatkach (spróbuj naprawić błędy, jeśli występują), teraz jest to wersja Y
• , jeśli te zmiany nie dotyczą żądania klienta zwróć na to szczególną uwagę i spróbuj dołączyć wersję X do wersji Y
• poinformuj (e-mailem) recenzenta i menedżera:

Myślę, że zakończyłem wdrażanie klient zażądał zmian w wersji X.
Aby odnieść się do uwag z recenzji, podjąłem następujące dodatkowe kroki dla wersji Y.

Wypisz tutaj swoje postępy i odkrycia, dołącz dokumentację tego procesu (krótka, maksymalnie 5-10 wierszy).
Jeśli poprawi to czytelność, możesz również umieścić tę listę na końcu e-mail i odnieś się do niego odpowiednio.

Jeśli uwagi z recenzji nie dotyczyły żądania klienta:
(poniżej wyjaśniono opóźnienie i początkową niezgodność z uwagami)

O ile mogłem stwierdzić (patrz mój raport powyżej / poniżej), same notatki z przeglądu nie byłyby odpowiedzią na prośby klientów i dodatkowo zaimplementowałem wersję X.

Napisałem wersję X jako pierwszą, aby upewnić się, że żądanie klientów zostało uwzględnione przed dodaniem innych zmian w kodzie.

Jeśli wersja Y nadal zawiera błędy, których nie można naprawić:
(Prawdopodobnie będą to notatki z recenzji lub dodanie wersji X do uwag z recenzji - dostosuj sformułowanie poniżej!)

Cieszę się, że mogę kontynuować pracę nad wersją Y.
Niestety integracja notatek z recenzji z wersją X (działający klient zażądał zmian) okazuje się bardziej złożona niż przedłożenie samej wersji X i będę potrzebować więcej czasu.

Jestem na płocie o uwzględnieniu poniższych informacji, aby nieco uspokoić recenzenta, jednocześnie wskazując kierownictwu, że jego zmiany powodują błędy. Może również spowodować, że kierownictwo zinterpretuje to, że nadal potrzebujesz nadzoru recenzentów.

wstaw imię i nazwisko recenzenta , jeśli masz chwilę, byłbym bardzo wdzięczny za wskazówki dotyczące motywacji stojącej za (lub być może mniej dociekliwe: „natura ") zmieni się kod i wynikające z tego błędy, które otrzymuję dla wersji Y.

Oczywiście użyj rzeczywistych numerów wersji zamiast X / Y (; mocne>

EDYTUJ:

Aby moja odpowiedź była bardziej czytelna i zwięzła, zmieniłem ją. Jeśli tak jest lepiej, zostaw komentarz. Dzięki.

Coś podobnego przytrafiło mi się - w mojej pierwszej pracy po studiach starszy programista musiał dokonać zmiany, aby wesprzeć coś, nad czym pracowałem, ale zmiana, którą wprowadził, nie zadziałała. W końcu pracowałem dla mnie i proponuję zrobić następujące rzeczy:

Zaangażuj innego starszego programistę, umów się na spotkanie z nimi obojgiem i wyjaśnij swój punkt widzenia. Jeśli to możliwe, zademonstruj przeprowadzone testy. Następnie pozwól mu wyjaśnić swoje podejście. Dowiedz się, co jest najlepszym rozwiązaniem i zrób to.

Upewnij się, że nie jesteś przeciwnikiem, coś w rodzaju:

Cześć Mike. Wygląda na to, że ciągle rozmawiamy o błędzie # 123. Czy masz 30 minut w poniedziałek, aby to omówić? Jim dołączyłby do nas, ponieważ ostatnio nad tym pracował

W mojej ostatniej pracy mieliśmy proces wzajemnej oceny. Kierownictwo poinformowało nas, abyśmy nie mówili tej osobie, jak rozwiązać ten problem, a jedynie udzielali wskazówek i wskazówek. Jako taki byłem na drugim końcu sytuacji w OP, gdzie jestem starszym programistą szkolącym nową osobę, która „naprawiła” problem, ale zmiany nie uwzględniają pewnych wyjątkowych sytuacji.

Sposób, w jaki to rozwiązałem, polegał na bezpośrednim wyjaśnieniu wyjątkowych sytuacji, a osoba była w stanie kodować wokół tego zachowania, ale ogólny kod był podatny na błędy, ponieważ był to starsze repozytorium. Uważam, że powinieneś zapytać programistę, czy jest jakaś wyjątkowa sytuacja, o której nie zdajesz sobie sprawy, że jest w stanie przewidzieć. Jeśli nie ma żadnych wyjątkowych przypadków, a on mówi, że jest „zepsuty”, ponieważ nie śledziłeś go, to mu go z powrotem. Napisz na bilecie kod działa, został przetestowany przez kierownictwo i niestety nie widzisz żadnej sytuacji, w której kod byłby błędny.

To dziwne, że odmawia twojej poprawki i odmawia podania szczegółów. Czas więc trochę eskalować. Oznacza to wysłanie wiadomości e-mail, którą wysłał do kierownika zespołu, mówiąc, że nie rozumiesz, dlaczego Twoja poprawka została odrzucona i nie rozumiesz funkcji na tyle, aby dowiedzieć się, co mówi Twój kolega, więc prosisz o pomoc TL.

Sformułowałbym to w kategoriach „starej funkcjonalności, której nie rozumiesz historii lub implikacji”, ale możesz chcieć to doprecyzować, ale idziesz do TL ”po pomoc to zadanie „wiedząc, że zobaczy ścieżkę zmian w kodzie (tj.„ pokaż mi, czego próbowałeś do tej pory ”), co uwydatni brak współpracy ze strony Twojego kolegi. To powinno wystarczyć, aby zapewnić temu zadaniu pewną widoczność w zespole i skupić się na jego naprawieniu, bez sztucznych i niepomocnych przeszkód ze strony współpracownika (który zachowuje się nieprofesjonalnie).

W żadnym momencie nie musisz tego robić narzekać, a nawet wspomnieć o nieprzydatności kolegi, to będzie jasne.

Jeśli nie masz lidera zespołu, umieść go z powrotem w kolejce „do zrobienia” i wspomnij (na spotkaniu o postępach?), że nie rozumiesz problemu wystarczająco, aby naprawić go już próbowałeś, więc zostawiasz to do naprawienia komuś bardziej doświadczonemu.

Twój kolega dał Ci kilka wskazówek i stwierdził, że musisz się nauczyć. Próbują być pomocni i udostępniają narzędzia do samodzielnego rozwiązywania podobnych problemów w przyszłości.

Wypróbowałeś ich wskazówki, ale z nieznanego powodu nie zadziałały (albo wskazówki się mylili, nie rozumieliście ich lub jakiejś kombinacji tych dwóch). Nie możesz samodzielnie rozwiązać żadnego z tych problemów, więc musisz zwrócić się o pomoc do recenzenta. Kiedy to robisz, powinieneś wyjaśnić recenzentowi, czego próbowałeś i dlaczego to nie zadziałało.

To pokazuje, że sam wkładasz wysiłek, zamiast polegać na jego doświadczeniu, aby rozwiązać problem (co może uczynić cię „wampirem pomocy”). Jeśli ich podpowiedzi były błędne, w tym momencie zdadzą sobie sprawę i będziesz mógł omówić inne rozwiązania. Jeśli źle zrozumiałeś ich wskazówki, lepiej zrozumieją Twoje myślenie i mogą przeformułować swoje wskazówki, aby odciągnąć Cię od nieporozumień.

Czytając komentarze, odpowiedzią, której zdawałeś się faktycznie używać, jest porozmawianie z osobą o swoich trudnościach i jej oczekiwaniach; a następnie zastanów się, dlaczego to, czego oczekiwali, nie zadziałało.

Bez względu na to, jakich narzędzi używa Twoja firma do śledzenia problemów, są to zazwyczaj narzędzia do prowadzenia dokumentacji i komunikacji; i chociaż mają swoje miejsce, myślę, że to pokazuje, że komunikacji werbalnej nie można zastąpić.

Szczerze mówiąc, powinno to być pierwsze miejsce, do którego należy zwrócić się w wielu kwestiach związanych z pracą; ponieważ to tylko część tego, jak pracować w zespole.