Jak rozbroić kowbojskiego programistę? [Zamknięte]

Znalazłem pytanie (kod kowboja w zespole), ale było bardziej związane z „Ninja Coder” niż z moim problemem.

Mam członka zespołu, który jest czysto żywym przykładem „ Cowboy Coder ”. Rozumiem, że nie można zmieniać ludzi, ale czy jest sposób, aby przestał zachowywać się jak „Cowboy Coder”?

Odmawia słuchania zespołu, a ostatnio przerwał przegląd kodu, testowanie jednostek, udostępnianie szczegółów implementacji itp.

Tak, szybko „koduje”, ale jego kod to tylko generator błędów. Inni członkowie zespołu i ja jesteśmy w „fazie naprawy błędów”, a 80% błędów pochodzi z jego kodu. Nie chcę naprawiać jego błędów. A zarządzanie jest ślepe, albo nie chce tego widzieć, a może lubią jego „szybkość”.

Czy jest jakiś sposób, że ja (jako jego młodszy kolega z wiekiem, a nie jego szef) mogę coś z tym zrobić?

Jak mogę rozbroić tego kowbojskiego programistę?

Czuję, że jestem ostatnim, który naprawdę dba o projekt.

Widzę kilka opcji:

• Podejdź do programisty ze swoimi obawami. Należy to zrobić jako konstruktywną krytykę z określonymi punktami. Przed podjęciem większych kroków należy zgłosić wątpliwości bezpośrednio i prywatnie, aby dać tej osobie możliwość zmiany.
• Zbierz informacje i statystyki i przekaż je zarządowi. Wygląda na to, że zarząd nie dba o to, ale często ważne jest, aby podjąć wysiłek w przypadku, gdyby zadziałało. Możliwe negatywne konsekwencje obejmują wyobcowanie innych, którzy nie doceniają skarg kierownictwa.
• Znajdź partnera kodera kowbojskiego i przedyskutuj to na osobności. Może mieć większą szansę na przekonanie osoby do słuchania.
• Poproś o pracę w innym zespole. Nie rozwiąże problemu, ale zachowasz zdrowie psychiczne. Przynajmniej zawsze pracuj najlepiej jak potrafisz i nie pozwól, aby cię to wciągnęło.
• Opuść organizację, jeśli nikt nie będzie słuchać. Brzmi jak złe środowisko.

Odmawia słuchania zespołu, a ostatnio przerwał przegląd kodu, testowanie jednostek, udostępnianie szczegółów implementacji ...

Recenzje kodu niekoniecznie wymagają od programisty przesłania pracy do recenzji.

Łatwym sposobem na śledzenie tego, co robi, jest śledzenie historii VCS, szukanie jego zameldowań. Jeśli martwisz się o jego kod, jest to łatwy sposób na jego znalezienie. Zapoznaj się z historią różnic, spójrz na to, co włożył i sprawdź, czy nie wyskoczą na ciebie jakieś czerwone flagi. Złap jego kontrole wystarczająco szybko, a jeśli znajdziesz problem, możesz cofnąć zatwierdzenie i wysłać go pocztą e-mail. Możesz wywoływać innych członków zespołu, nawet jako młodszy programista, gdy zobaczysz coś wyraźnie nie tak.

Tak, szybko „koduje”, ale jego kod to tylko generator błędów. Inni członkowie zespołu i ja jesteśmy w „fazie naprawy błędów”, a 80% błędów pochodzi z jego kodu. Nie chcę naprawiać jego błędów. A zarządzanie jest ślepe, albo nie chce tego widzieć, a może lubią jego „szybkość”.

Kod pochodzi z wymagań. Wymagania powodują uruchomienie testów, które potwierdzają, że wymagania zostały spełnione. Testy te można dalej podzielić i zapisać przed dokonaniem zmian, aby sprawdzić, czy zmiany spełniają wymagania (refaktor czerwono-zielony; esencja TDD).

Dodaj wskaźnik „pokrycia kodu” do serwera kompilacji zespołu (mam nadzieję, że go masz; jeśli nie, to twój pierwszy problem). Samo sprawdzenie, czy testy jednostkowe pomyślnie przeszły, nie uchwyci problemów z nowym kodem nie TDDed, wykonanym w obszarach, które nie mają testów jednostkowych. Po uruchomieniu wszystkich testów jednostkowych serwer kompilacji powinien idealnie wykonać każdą linię kodu, ale naprawdę jest kilka rzeczy, których po prostu nie można przetestować. Realistycznie powinieneś być w stanie oczekiwać 95% lub więcej pokrycia (lub wykluczyć niektóre biblioteki lub typy plików z pokrycia). Wcześniej czy później twój kowboj zarejestruje coś, co psuje kompilację, ponieważ obniżył poziom zasięgu poniżej progu, a ty go wołasz.

Jeśli chodzi o „prędkość”, prędkość to szybkość, z jaką „załatwiasz” rzeczy, i nie jest ona „wykonywana”, dopóki nie zostanie wykonana poprawnie. W ten sposób możesz przekazać to swoim menedżerom; rozważ mechanika samochodowego, który, gdy menedżer zabiera BMW w celu wymiany oleju, zapomina o ponownym wkręceniu korka miski olejowej, w wyniku czego cały nowy olej wylewa się przed wyjazdem z garażu. Jasne, wymiana oleju zajęła tylko pięć minut, ale menedżer nie będzie się tym przejmował, gdy silnik samochodu zapali się w drodze do domu. Będzie się troszczył o to, aby mechanik przegapił krok, co będzie kosztowało go dużo dodatkowego czasu i pieniędzy na naprawę. W tej chwili płaci jednemu kowbojowi za naprawdę szybką robotę, a potem „ płaci reszcie zespołu znacznie większą sumę, aby wejść i poprawnie wykonać zadanie ponownie. Jaka jest w rzeczywistości korzyść z tego, że nadal pozwala kowbojowi robić swoje rzeczy?

Czy jest jakiś sposób, że ja (jako jego młodszy kolega z wiekiem, a nie jego szef) mogę coś z tym zrobić?

Zawołaj go. Kiedy znajdziesz coś, co spieprzył, pokaż mu, jak zawodzi jego kod, w jaki sposób mógł w pierwszej kolejności zapobiec problemowi (w tym odpowiedni projekt, TDD, recenzje kodu) i co zrobiłeś lub będziesz musiał zrobić w wyniku naprawić jego zepsuty kod.

Czuję, że jestem ostatnim, który naprawdę dba o projekt.

rozbrzmiewające klaksony, migające światła, wycie syren - jeśli naprawdę czujesz, że jesteś jedyną osobą, która dba o jakość kodu produkowanego przez zespół, oznacza to POWAŻNY problem. Jeśli czujesz, że próbujesz przeciągnąć cały zespół kopiąc i krzycząc w epokę dobrego kodowania, a to po prostu zbyt duża waga do ciągnięcia, to porzuć. Jeśli jest inny zespół w firmie, który robi to dobrze, poproś o przeniesienie, w przeciwnym razie wynoś się.

Przejdź do zarządzania ze swoimi statystykami na temat liczby błędów / problemów pochodzących od tego jednego programisty. Wyjaśnij im, że usunięcie ich błędów wpływa na produktywność twojego zespołu. Jeśli rzeczywiście 80% problemów pochodzi od jednej osoby, na pewno należy to rozwiązać. Dopóki wyjaśnisz to kierownictwu w terminach, z którymi mogą się zgodzić (tj. „Marnowany czas to marnowane pieniądze”), będą interweniować.

Ponadto ten programista powinien naprawiać własne błędy / problemy, więc może być pomocne przypisanie im tych problemów. Twój zespół nie powinien obejmować tej jednej osoby.

Czy jest jakiś sposób, że ja (jako jego młodszy kolega z wiekiem, a nie jego szef) mogę coś z tym zrobić?

Jedyną dobrą drogą jest presja otoczenia i dawanie przykładu. Najlepsze sposoby robi ich szef / szef. Jeśli nie jesteś ich szefem / przywódcą, porozmawiaj z tymi, którzy są. Ale ostatecznie ich zadaniem jest zająć się tym, a nie twoim. Upewnij się, że wykonujesz dobrą robotę, a rzeczy same się układają.

Odmawia słuchania zespołu, a ostatnio przerwał przegląd kodu, testowanie jednostek, udostępnianie szczegółów implementacji ...

Czy nie masz udokumentowanej ścieżki do kodu poprzez przegląd, testowanie i wdrożenie? Jeśli nie, masz szerszy problem. Jeśli to zrobisz, musisz to eskalować.