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ę.