Radzenie sobie ze współpracownikami przy opracowywaniu, potrzebujesz porady [zamknięte]

Opracowałem naszą obecną architekturę projektu i zacząłem ją rozwijać samodzielnie (osiągając coś w rodzaju, revision 40) .

Opracowujemy prostą strukturę routingu metra i mój projekt wydawał się być wykonany bardzo dobrze - kilka głównych modeli, odpowiadające widoki, główna logika i struktury danych zostały zamodelowane „tak, jak powinny” i całkowicie oddzielone od renderowania, część algorytmiczna została również zaimplementowana oprócz głównych modeli i miał niewielką liczbę punktów przecięcia.

Nazwałbym ten projekt skalowalnym, konfigurowalnym, łatwym do wdrożenia, działającym głównie w oparciu o „interakcję z czarną skrzynką” i, no cóż, bardzo fajny.

Co zostało zrobione:

• Rozpocząłem implementacje odpowiednich interfejsów, przeportowałem wygodne biblioteki i napisałem kody pośredniczące dla niektórych części aplikacji.
• Miałem dokument opisujący styl kodowania i przykłady użycia tego stylu kodowania (mój własny kod napisany).
• Zmusiłem się do użycia mniej lub bardziej nowoczesnych C++technik programistycznych, w tym no-deletekodu (opakowanego za pomocą inteligentnych wskaźników) itp.
• Udokumentowałem cel konkretnych implementacji interfejsu i sposób ich wykorzystania.
• Testy jednostkowe (głównie testy integracyjne, ponieważ nie było dużo „rzeczywistego” kodu) i zestaw próbnych prób dla wszystkich podstawowych abstrakcji.

Byłem nieobecny przez 12 dni .

Co mamy teraz (projekt został opracowany przez 4 innych członków zespołu):

• 3 różne style kodowania całego projektu (Chyba, dwa z nich zgodził się użyć tego samego stylu :) , samo odnosi się do nazywania naszych abstrakcji (np CommonPathData.h, SubwaySchemeStructures.h) , które są w zasadzie nagłówki deklarujące niektóre struktury danych.
• Absolutny brak dokumentacji dla ostatnio wdrażanych części.
• To, co mogłem ostatnio nazwać single-purpose-abstractionteraz, obsługuje co najmniej 2 różne typy zdarzeń, ma ścisłe połączenie z innymi częściami i tak dalej.
• Połowa używanych interfejsów zawiera teraz zmienne składowe (sic!).
• Surowe użycie wskaźnika prawie wszędzie.
• Testy jednostkowe wyłączone, ponieważ „ (Rev.57) They are unnecessary for this project”.
• ... (to chyba nie wszystko) .

Historia Commit pokazuje, że mój projekt został zinterpretowany jako przesada i ludzie zaczęli go łączyć z osobistymi rowerami i ponownie zaimplementowanymi kołami, a następnie mieli problemy z integracją fragmentów kodu.

Teraz - projekt nadal wykonuje tylko niewielką część tego, co musi zrobić, mamy poważne problemy z integracją, zakładam, że wycieki pamięci.

Czy w tej sprawie jest coś do zrobienia?

Zdaję sobie sprawę, że wszystkie moje wysiłki nie przyniosły żadnych korzyści, ale termin jest już niedługo i musimy coś zrobić. Czy ktoś miał podobną sytuację?

Zasadniczo myślałem, że dobry (cóż, zrobiłem wszystko, co mogłem) początek projektu prawdopodobnie doprowadzi do czegoś fajnego, jednak rozumiem, że się mylę.

Refaktoryzuj bezlitośnie, aby wydostać się z bałaganu!

Weź styl kodowania, który odpowiada za większość użytecznego stylu i użyj go w tym projekcie.

Najgorsze jest to, że musisz cofnąć się do wersji 40, a twoi programiści odbyli 12-dniową sesję szkoleniową, która pozwoliła im lepiej zrozumieć ten temat.

Jeśli twoi programiści mają tyle do nauczenia się o czystym kodowaniu, dwanaście dni to najmniejsze opóźnienia, jakie możesz mieć.

Parafrazując twoje pytanie: „Odszedłem na kilka tygodni i nie zgadzam się z tym, co mój zespół zrobił, kiedy mnie nie było, jak sprawić, by robili to, co chcę, kiedy mnie tu nie ma?”

Powiem wam, że to nie jest problem techniczny, to problem zarządzania. Uważam (proszę wybacz mi, jeśli się mylę), że dyktujesz techniczne rozwiązanie armii stworów, które z jakiegoś powodu albo nie mogą, albo nie zgadzają się z twoim rozwiązaniem lub go nie rozumieją.

Jeśli 12 dni wystarczyło, aby zrobić tyle szkód w twoim projekcie, musi być jakiś powód. Czy projekt jest kruchy? czy to już inżynieria? czy zespół po prostu zrobił to na przekór? Jakie są twoje terminy i dostawy? Mocno? czy oni tylko próbowali się z nimi spotkać?

W jednym z przypadków widziałem to, że przewaga techniczna była tak daleko przed grą, że przeciętny programista (ja) nie był w stanie nadążyć. Kierownik techniczny nie zaprojektował komercyjnie opłacalnego kodu, ponieważ był jedynym, który mógł go utrzymać. Jeśli programista grad nie może go utrzymać, jest to zbyt skomplikowane dla świata komercyjnego. We wszystkich innych przypadkach był to po prostu brak umiejętności zarządzania ludźmi po stronie zarządzania.

Dynamika drużyny jest zepsuta. Możesz (jak sugerują inni) spędzić czas na refaktoryzacji bałaganu i musisz zrobić to wszystko ponownie, kiedy wyjdziesz. Może być konieczne podniesienie umiejętności członków zespołu, ale uważam, że musisz najpierw poprawić dynamikę zespołu, ponieważ wydają się mieć wystarczającą liczbę umiejętności, aby wykonać pracę, bez względu na to, jak brzydka jest.

Para.

To, co opisujesz, to robienie tego dobrze, technicznie, solo . Tak, próbowałeś dokumentować, próbowałeś narzucić standardy - ale najwyraźniej nie udało ci się nawiązać komunikacji.

Twój zespół właśnie się z tobą skontaktował, dość głośno. Powiedzieli: „Hej, Yippie - nie komunikujesz się!” Najpotężniejszą formą komunikacji, jaką znam, jest parowanie. Para. Dopóki go nie zdobędą lub dopóki nie przekonają cię do zrobienia tego inaczej.

Jak powiedział nam Brooks przez ostatnie 30 lat, integralność koncepcyjna jest najważniejszą częścią każdego projektu. W przypadku każdego nietrywialnego i kompletnego podsystemu powinna być dokładnie jedna osoba odpowiedzialna za jego projekt i uprawniona do kierowania jego wdrażaniem. Coś poszło nie tak z tą częścią twojego projektu. Cokolwiek to było, jedynym rozwiązaniem jest przywrócenie kodu w repozytorium, który istniał przedtem. Utrata 12 dni to nic w porównaniu z kosztami utrzymania zepsutego projektu. Pomyślałbym również o sposobach usunięcia osób zaangażowanych w tę dorastanie z dalszej pracy nad projektem, ponieważ okazały się niekompetentne.

Jedną rzeczą, którą zrobiłbym na początek, jest zdobycie dobrego narzędzia do przeglądu kodu, używającego go do oznaczania złego kodu i dokumentowania, dlaczego jest zły i (koncepcyjnie), jak należy to zrobić. Teraz, z tego co zrozumiałem, zrobiono wiele złych rzeczy, więc przeglądanie byłoby dużo pracy; zakładając, że jesteś jedynym, który widzi coś złego w kodzie, sprawdzenie wszystkiego samodzielnie może być niewykonalne. Możesz jednak oznaczyć najgorsze przestępstwa i zamienić je we wpisy w systemie śledzenia problemów przypisane do osoby, która napisała odpowiedni kod.

Najlepszą zachętą do pisania kodu jakości jest to, że jeśli tego nie zrobisz, będzie cię to prześladować w przyszłości. Wydaje się, że Twoi współpracownicy nie przejmują się tym, więc najlepszym lekarstwem jest sprawienie, by sami zmienili niewłaściwe części i nauczyli się.

Po pewnym czasie możesz ponownie przejrzeć inne części kodu, które są problematyczne, i ponownie przypisać do oryginalnego (złego) autora. Po chwili zdadzą sobie sprawę z korzyści, jakie daje dobra robota za pierwszym razem.

Zakładam, że przywrócenie oryginalnej wersji nie jest możliwe - innymi słowy, pomimo złego kodu napisanego przez współpracowników, dodali oni pewną funkcjonalność, a wartość netto bieżącej wersji jest wyższa niż oryginalna. Zakładam również, że nawet jeśli tak nie jest, nie masz kapitału politycznego, aby cofnąć kod i zmusić go do przepisania kodu (ponieważ niewiele osób na świecie ma taki kapitał). Te i wiele innych rzeczy to złożoność oceny sytuacji, której sam nie doświadczam, ale mam nadzieję, że moje dwa centy pomogły.

Jedną z rzeczy, o których nie wspomniałem, ale które ostatnio pojawiły się w mojej pracy, są problemy z „silosami programistów” i „wpisami”.

Na początku mojego obecnego projektu ostatecznie sam zaprojektowałem bibliotekę podstawową. (Podobnie jak zrobiłeś do rev. 40). Kiedy to zrobiłem, przedstawiłem się reszcie zespołu i powiedziałem wszystkim, że mogą zacząć z niego korzystać. W kolejnych miesiącach ludzie wdrażali te same rzeczy, które były już w tej bibliotece w innych miejscach. CTO (który aktywnie koduje) zwraca uwagę, że reszta zespołu nigdy nie miała poparcia dla architektury / projektu / publicznych interfejsów biblioteki.

Właśnie przeszliśmy gruntowną przeróbkę tej biblioteki, która prawdopodobnie poprawiła ogólny projekt, aby lepiej pasowała do tego, co obecnie robimy, ale ponownie programista wziął bibliotekę jako swój jedyny projekt, pracował nad nią przez kilka tygodni i po prostu to przedstawiłem. „Voila! Oto jest! Czyż nie jest ładna?”

Teraz, gdy muszę korzystać z nowej wersji i pojawia się ten sam problem - nie znoszę sposobu, w jaki to zrobił. I pominął rzeczy, które były konieczne, ponieważ nie współpracował z nikim innym, gdy nad tym pracował. Znowu zaczynam wdrażać te same rzeczy w innych miejscach i sposobach pracy nad tym, co muszę zrobić.

Krótko mówiąc - jeśli chcesz, aby jakość kodu wzrosła i była spójna, sugerowałbym, aby zebrać cały zespół, aby ustanowić standardy, style itp. Ponadto, za każdym razem, gdy ktoś zamierza zbudować fundamentalny lub podstawowy element twojego aplikacji, sugerowałbym, aby osoba odpowiedzialna poprowadziła cały zespół w projektowaniu zajęć itp., aby na koniec cały zespół musiał wkupić się w ogólną architekturę aplikacji. Ponadto, jeśli wiedzą, jak działa kod innego członka zespołu, będzie mniej prawdopodobne, że wdroży go ponownie w sposób, który będzie dla nich odpowiedni.

Czy jesteś starszym programistą (lub jednym ze starszych programistów) w tym zespole? Jeśli tak, wydaje się, że musisz zorganizować seminaria szkoleniowe na temat najlepszych praktyk. Prawdopodobnie powinieneś cofnąć większość wykonanej pracy, zorganizować spotkanie ze swoim zespołem i wyjaśnić właściwy sposób wdrożenia wymaganej funkcjonalności w sposób, który zachowuje istniejący projekt.

Biorąc pod uwagę napięty termin, może być konieczne wysłanie kodu w stanie, w jakim się znajduje, i ponowne wydanie (przepisanie?) Po wydaniu.

Brzmi również tak, jakbyś musiał zdefiniować i egzekwować niektóre popularne praktyki kodowania. Czy masz w pracy proces weryfikacji kodu? Jeśli nie, wydaje się, że teraz jest czas na jego wdrożenie. Nawiasem mówiąc, recenzje kodu to świetny sposób na nauczenie nowszych programistów najlepszych praktyk.

EDYTOWAĆ:

Niedawno wpadłem na podobną sytuację. Kierownictwo mojej firmy nalegało, abyśmy używali programistów kontraktowych do pisania większości naszej aplikacji. Kod, który stworzyli, był okropny (delikatnie mówiąc), ale byliśmy zmuszeni go użyć. Na dzień dzisiejszy przepisałem 80% kodu, który napisali dla nas kontrahenci. Było pełne błędów i niemożliwe do rozszerzenia o nowe funkcje. Za kilka miesięcy mój zespół przeredaguje to wszystko, skutecznie marnując pieniądze zainwestowane w rozwój kontraktów.

Zły kod naprawdę kosztuje, dlatego warto porozmawiać z menedżerami, ponieważ prawdopodobnie będziesz potrzebować ich pomocy przy wdrażaniu i egzekwowaniu standardów kodowania.

Podjęliście wysiłek, ale faktem jest, że nikt nie rządzi . „Ale wolę swój styl kodowania”, bez gówna. Chciałbym pracować nad moimi osobistymi projektami przez cały dzień i nadal otrzymywać wynagrodzenie.

Mamy nadzieję, że możesz przedstawić to obecnym mocom i pokazać im, co można było zrobić w przeciwieństwie do pokazu Dzikiego Zachodu, który trwał przez dwa tygodnie. Wydaje się, że będziesz musiał wyciągnąć coś za drzwi, ale kontynuuj śledzenie problemu braku kontroli i konsekwencji.

Skoncentruj się na kilku, które były zgodne z Twoim planem i zrób wszystko, co w ich mocy, aby naprawić ten bałagan i dostać się do swojego zespołu w przyszłych projektach. Być może będziesz musiał odrzucić resztę, jeśli nie będą w stanie tego zebrać.