W jaki sposób menedżer ds. Rozwoju powinien obsługiwać kod „Obsługa celów”?

Najpierw pozwól mi wykreślić termin:

celowanie kodu: sprawdzanie kodu rano, a następnie dyskretne przeglądanie wszystkich zmian dokonanych przez innych programistów poprzedniego dnia plik po pliku (zwłaszcza pliki kodu, które pierwotnie opracowałeś) oraz poprawianie formatowania, logiki, zmiany nazw zmiennych, refaktoryzacja długie metody itp., a następnie zatwierdzanie zmian w VCS.

Ta praktyka ma zwykle kilka zalet i wad, które zidentyfikowałem:

• Pro : Często zachowywana jest jakość / czytelność / spójność kodu
• Pro : Niektóre błędy zostały naprawione, ponieważ inny programista nie był zbyt zaznajomiony z oryginalnym kodem.
• Przeciw : Często marnuje czas dewelopera dążącego do celu.
• Con : Od czasu do czasu wprowadza błędy, które wywołują wściekłość przez programistów, którzy myśleli, że napisali kod wolny od błędów poprzedniego dnia.
• Przeciw : Inni programiści denerwują się nadmiernym nitpickingiem i zaczynają nie lubić przyczyniać się do kodowania oferty bramkowej.

Oświadczenie: Aby być uczciwym, właściwie nie jestem menedżerem ds. Rozwoju, jestem programistą, który faktycznie zajmuje się „utrzymywaniem celu”.

W mojej obronie myślę , że robię to z ważnego powodu (aby utrzymać naszą bardzo dużą bazę kodu dobrze naoliwioną maszyną), ale jestem bardzo zaniepokojony, że powoduje to również negatywną atmosferę. Jestem również zdecydowanie zaniepokojony, że mój kierownik będzie musiał rozwiązać ten problem.

Więc gdybyś był kierownikiem, jak rozwiązałbyś ten problem?

AKTUALIZACJA: Nie chcę, żeby to było zbyt zlokalizowane, ale niektórzy o to prosili, więc być może jakieś tło się rozjaśni. Przydzielono mi gigantyczny projekt (200 000 LoC) trzy lata temu, a dopiero niedawno (1 rok temu) do projektu zostali dodani kolejni programiści, z których niektórzy nie znają architektury, inni wciąż uczą się języka (C #). Zasadniczo muszę odpowiadać za ogólną stabilność produktu i jestem szczególnie zdenerwowany, gdy niespodziewanie wprowadzane są zmiany w podstawowych częściach architektonicznych podstawy kodu. Ten nawyk pojawił się, ponieważ początkowo byłem optymistycznie nastawiony do wkładu innych programistów, ale popełnili oni zbyt wiele błędów, które spowodowały poważne problemy, które nie zostaną odkryte dopiero po kilku tygodniach, gdy palec zostanie skierowany na mnie za pisanie niestabilnego kodu. Często te „

Wygląda na to, że to, co robisz, jest w zasadzie równoznaczne z recenzją kodu, z tą różnicą, że zamiast przekazywać opinie programistom, wprowadzasz wszystkie zmiany, które zasugerowałbyś podczas recenzji kodu. Prawie na pewno lepiej byłoby zrobić przegląd kodu, w którym Ty (lub ktoś inny) przekażesz oryginalnemu programistowi opinie na temat problemów z jakością kodu i oczywistych błędów i poprosisz oryginalnego programistę o ich naprawienie. Utrzymuje to jakość kodu, ale pomaga także deweloperowi lepiej zapoznać się z oryginalnym kodem i jego pułapkami oraz pomaga poprawić przyszłe zmiany kodu. Co więcej, nie ma to wady, że powoduje „wściekłość”, gdy błąd zostaje cicho wprowadzony, lub powoduje, że inni programiści myślą, że mówi się o nich za ich plecami.

Szczerze mówiąc, IMHO, to okropny pomysł.

Spodziewałbym się, że morale spadnie do rynny, jeśli jeszcze tego nie zrobiło.

Mówiąc szczerze, uznajesz to.

Recenzje kodu równorzędnego są w porządku, nakładają na deweloperów wszystko na jednym poziomie, zamiast scenariusza „one kontra my”. (gdzie są to zarząd / potencjalni klienci).

Być może niektórzy programiści powinni pilnować więcej niż inni, ale koc zmuszający cały kod, który pierwszy przejdzie przez ciebie, jest niedorzeczny.

I pomimo tego, jak dobrze myślisz, że będziesz, zdarzają się chwile, kiedy się mylisz lub „zrywanie nitów”, a to tylko pogorszy sytuację.

Gdybym był kierownikiem, aby rozwiązać ten problem:

• Przejrzyj standardy kodu i praktyki z zespołem, przekaż im kopię standardów kodowania
• Regularnie recenzuj kod, aby wzmocnić standardy i praktyki, których należy przestrzegać
• Wymuszaj nitpicking / formatowanie za pomocą narzędzia do automatyzacji, aby programiści byli zmuszeni do przestrzegania standardów
• Pozbądź się złych członków drużyny, którzy odmawiają przestrzegania standardów
• Przestań być bramkarzem

Twoje intencje są dobre, ale wdrożenie jest okropne i, jak zauważyli inni, spowoduje złe morale i snajper wśród członków zespołu.

Jeśli projekt nigdy nie miał żadnego standardu na początku, spróbuj stopniowo wprowadzać nowy standard, zamiast po prostu naciskać przełącznik.

Bad juju.

Nie jestem menedżerem ds. Rozwoju, ale gdybym tak był, nie chciałbym, aby którykolwiek z moich programistów dotknął kodu, który nie jest częścią defektu lub przypisanej funkcji. Kropka. Jeśli zauważysz problem z kodem innej osoby, to z całą pewnością zwróć na to uwagę odpowiedzialnego programisty (programistów), ale nie po prostu zanurkuj i napraw go samodzielnie, zwłaszcza jeśli nie koordynowałeś go z innym programistą ( s) po pierwsze.

Zadania czyszczenia powinny być wykonywane tylko po formalnym przeglądzie kodu przez zespół i tylko przez programistów, którym te zadania zostały przypisane.

Inicjatywa jest ogólnie dobra, ale czasami może cię ugryźć w tyłek. Jeśli wprowadzi jakieś błędy w to, co zostało kodeksu pracy, może szybko zostać chcąc którą wybrał inną ścieżkę kariery.