Na końcu mojej liny [zamknięty]

Jestem kontrahentem dużej firmy. Obecnie w projekcie jest trzech programistów, w tym ja.

Problem polega na tym, że dwóch innych programistów tak naprawdę tego nie rozumie. Przez „to” rozumiem, co następuje:

• Nie rozumieją najlepszych praktyk dotyczących używanej przez nas technologii. Po 6 miesiącach ode mnie i innych, podając im przykłady, stosuje się straszne anty-wzory.
• Są programistami „kopiuj i wklej”, którzy produkują głównie kod spaghetti.
• Oni ciągle łamać rzeczy, wprowadzanie zmian, ale nie robi podstawowy test dymu aby sprawdzić, czy wszystko jest dobrze
• Odmawiają / rzadko proszą o recenzje kodu.
• Odmawiają / rzadko robią nawet podstawowe rzeczy, takie jak formatowanie kodu.
• Brak dokumentacji dotyczącej jakichkolwiek klas (jsdocs)
• Boję się usunąć kod, który nic nie robi
• Skomentuj bloki kodu wszędzie, mimo że mamy kontrolę wersji.

Czuję się coraz bardziej sfrustrowany, gdy formatuję inne kody, naprawiam błędy, odkrywam zepsute funkcje i tworzę abstrakcje, aby usunąć spaghetti.

Naprawdę nie wiem co robić. Staram się nie denerwować, ale to tylko bałagan. Lubię tych ludzi jako ludzi, ale mam wrażenie, że sytuacja w kodowaniu jest tak zła, że ​​mógłbym poruszać się szybciej, gdyby po prostu przeglądali Internet przez cały dzień.

Czy nie byłoby w porządku poprosić naszego kierownika o sprawdzenie dostępu svn commit; zatwierdzeń może dokonać tylko osoba, która ma wiedzę na temat tego, co robimy? Jako kontrahent nie jestem pewien, czy to najlepszy ruch.

Czy istnieje subtelny / nie tak subtelny sposób wyjaśnienia, ile rzeczy naprawiam?

Mam coś takiego w moim zespole. Starałem się, aby ludzie robili to, co należy, i nie działało to zgodnie z oczekiwaniami, więc przeszedłem do innego rozwiązania.

Najpierw poszedłem do mojego menedżera i wypracowaliśmy umowę, żaden kod nie dostaje się do kontroli źródła, chyba że jest objęty testami jednostkowymi. Jeśli kod wejdzie bez testów jednostkowych, mam prawo weta, aby natychmiast cofnąć zatwierdzenie i pingować tego, kto był odpowiedzialny, może pracować nad testami, a następnie przesłać kod.

Mając tę ​​zasadę, regularnie uruchamiam narzędzia do pokrywania kodu (w tym przypadku jacoco w naszej kompilacji sbt ), aby upewnić się, że elementy są poprawnie zakryte, a także stale refaktoryzuję i przeglądam kod w każdym kodzie przez nich przekazywanym. Ponieważ jest to projekt Java i Scala , mam mnóstwo narzędzi, które pomagają mi wychwycić rzeczy, których nie powinno być lub które nie działają tak, jak naszym zdaniem powinny, nie jestem pewien, jak możesz zrobić to samo z JavaScript, ale może jest rozwiązanie.

Najważniejszą rzeczą, która moim zdaniem pomaga mi nadążyć za tym, jest to, że mam jasny obraz tego, czego oczekuję od projektu i jego głównej architektury, więc za każdym razem, gdy widzę coś, co nie odzwierciedla tego widoku, mogę tam iść i napraw to. Powinieneś zrobić to samo, zdefiniować swój widok, wzorce, które należy zastosować, sposób pisania kodu i być na bieżąco, zawsze pozwalając im (i kierownictwu) wiedzieć, co się dzieje i co powstrzymuje projekt przed kontynuowaniem szybciej.

Z pewnością nadejdzie moment, w którym albo się poddadzą i zrobią coś dobrego, albo zarząd dostanie komunikat i usunie je z projektu.

Jestem pewien, że do tej pory widziałeś moje komentarze i mój inny post, więc nie będę udawał, że naprawdę znam odpowiedź. Najlepsze, co mogę zaoferować, to podsumowanie tego, co słyszałem / czytałem od innych, i dodałem własne doświadczenia do miksu.

Po pierwsze, chcę powiedzieć, że jakiś czas temu natknąłem się na blog, który należy do jednego z naszych członków Programmers SE, Martina Blore'a i IMO, ten konkretny post na temat samorealizacji TDD jest bardzo dokładny. TDD to ostatni, najwyższy poziom, który łączy wszystko razem, ale bez wcześniejszych poziomów, zwłaszcza największego, zasad i praktyk tworzenia jasnego i czytelnego kodu, bardzo trudno będzie, jeśli nie uniemożliwić, działanie TDD.

W mojej firmie zarówno Agile, jak i TDD zostały narzucone nam przez kierownictwo i na początku po prostu to zrobiliśmy, ponieważ powiedziano nam (co jest przeciwieństwem zwinności). Próbowaliśmy dwa razy TDD i chociaż jestem wielkim zwolennikiem korzystania z testów automatycznych, osobiście wyrzuciłem wszystkie te, które zespół spasował w ostatnim wydaniu. Były kruche, gigantyczne, kopiowały / wklejały wazoo i były wypełnione oświadczeniami dotyczącymi snu, które powodowały, że biegali naprawdę wolno i nieprzewidywalnie. Moja rada dla twojego zespołu: NIE ROBIJ TDD ... jeszcze.

Nie wiem, jaka jest twoja sytuacja, ponieważ wspomniałeś, że jesteś w firmie tylko przez 6 miesięcy i że jesteś wykonawcą. Czy Twoim długoterminowym celem jest pozostanie w tej firmie, czy też umowa się skończy? Pytam, bo nawet jeśli coś zrobisz, uzyskanie wyników może zająć sporo czasu.

Również kiedy dołączasz do zespołu, zwykle potrzeba czasu, zanim zdobędziesz wystarczającą wiarygodność i szacunek dla swojego zespołu, w którym oni (programiści i kierownictwo) rozważą nawet wszystko, co zaproponujesz. Z mojego doświadczenia wynika, że ​​gasisz kilka pożarów i demonstrujesz, że masz umiejętności i wiedzę, na których inni mogą polegać. Nie jestem pewien, czy wystarczy 6 miesięcy. Dość często nowa, ambitna osoba dołączała do zespołu, a następnie pisała tutaj post z pytaniem, w jaki sposób może zmienić świat. Smutna rzeczywistość jest taka, że ​​po prostu nie mogą.

Zakładając, że masz szacunek i uwagę swojego zespołu. Co teraz?

Po pierwsze, zarówno kierownictwo, jak i programiści muszą mieć świadomość, że występuje problem. Wyniki pomiaru mierzone są pod względem wykonanej pracy. Jeśli są zadowoleni z obecnej ilości i jakości funkcji, smutną rzeczywistością jest to, że nie będą słuchać. Jak zauważyli inni, bez wsparcia kierownictwa niezwykle trudno będzie wprowadzić jakąkolwiek zmianę.

Gdy uzyskasz wsparcie zarządzania, następnym krokiem jest dogłębne zbadanie i określenie głównych przyczyn, dla których zespół działa w ten sposób. Ten następny temat jest czymś, co było moją osobistą misją od jakiegoś czasu. Jak dotąd była to moja podróż:

1. Po uzyskaniu wsparcia kierownictwa. Możesz zacząć wprowadzać wiele centralnie podyktowanych praktyk / procesów, które MainMa zasugerowało w odpowiedzi na moje pytanie . Zrobiliśmy wiele z nich (z wyjątkiem programowania w parach) i na pewno widzisz korzyści. Recenzje kodu szczególnie pomogły w ujednoliceniu stylizacji, dokumentacji, a także pozwoliły nam dzielić się wiedzą / technikami wśród zespołu. Mimo że recenzje kodu były podyktowane, zespół naprawdę je lubi i sprawdzamy każdy sprawdzony element funkcjonalności. Jednak ...
2. Zauważysz, że ogólnie napisany kod jest nadal zbyt powiązany, projekt jest zły lub całkowicie go brakuje. Recenzje kodu łapią niektóre z nich, ale jest tylko tyle rzeczy, które możesz przepisać. Dlaczego projekt jest zły? - Wielu programistów nigdy nie zapoznało się z dobrymi praktykami i nigdy nie było oficjalnie nauczane OOD. Wiele osób po prostu „zakodowało” każde zadanie, które im powierzono.
3. Dzięki wsparciu kierownictwa możesz wprowadzić więcej procesów, takich jak omawianie projektu, zanim nastąpi jakiekolwiek kodowanie. Ale jesteś tylko jedną osobą i wydaje się, że gdy tylko nie zwrócisz uwagi, zespół powraca do tego, co zawsze robił. Dlaczego?
4. Czy można wprowadzić i nauczyć lepszych praktyk lub nawyków, abyś nie musiał stale monitorować? - Okazuje się, że ta część nie jest taka łatwa.
5. Dlaczego inni członkowie zespołu niechętnie uczą się i wybierają nowe praktyki i dlaczego są tak odporni na SOLID lub DRY, skoro tak wiele o nich napisano we współczesnej literaturze metodologicznej? Po wszystkich pozytywnych zmianach, które wprowadziliśmy w moim zespole, 2 tygodnie temu miałem kłótnię, gdy zreformowałem 2 funkcje, które miały identyczne 15 linii kodu, a recenzent nazwał to heroicznym, niepotrzebnym wysiłkiem, ponieważ nie ma nic złego w kopiowaniu / wklejaniu tylko 15 linii. Zdecydowanie nie zgadzam się z takimi poglądami, ale na razie postanowiliśmy się nie zgodzić. -- I co teraz? Teraz dotarliśmy do tematu mojego drugiego postu .
6. Jak wskazali w swoich odpowiedziach maple_shaft i nikie (przepraszam, MainMa , masz najwięcej głosów, ale jesteś o 5 kroków w tyle :)), osiągnąłeś etap, w którym „proces” nie może ci pomóc i nikomu na tym forum może powiedzieć ci, co to jest „poprawka”. Następnym krokiem jest podejście do osób, może jeden na jednego, może jako zespołu, prawdopodobnie zarówno w tym samym czasie, jak i rozmowy z nimi. Zapytaj ich, co działa, a co nie. Jedynym sposobem na zidentyfikowanie głównej przyczyny tego, co je napędza, jest teraz rozmowa z nimi indywidualnie i przekonanie się o tym. W ramach tego kroku natknąłem się na zupełnie inny problem zespołowy, ale myślę, że odpowiedź Joela tutaj, który jest bardzo szczegółowy i wnikliwy, dotyczyłby również tej sprawy. Podsumowując, chociaż stosowanie zarządzania jako „krótkiej smyczy” jest możliwym podejściem do wszystkiego, musimy pamiętać, że mamy do czynienia z ludźmi, więc aby naprawdę zrozumieć motywacje, musimy przejść bardziej w psychoanalizę niż samo zarządzanie lub techniczne przywództwo.
7. Więc teraz rozmawiasz z kolegami z drużyny? O co ich pytasz Nie jestem pewien co do następnej części, ponieważ nigdy tu nie byłem. Oto możliwy scenariusz: P: Dlaczego nie ma SOLID? Odp .: Nie potrzebuję tego. P: To może pomóc. Odp .: Nic mi nie jest. - w jakiś sposób musisz wygenerować serię dźwięków, które opuściłyby twoje usta i sprawiły, że słuchacz rozpoznał, że mogłoby być lepiej, gdyby dawały szansę temu, co masz. Jeśli ci się tu nie uda, nigdy nie będą przekonani, że cokolwiek „proces” sprawia, że ​​faktycznie mają jakąkolwiek wartość. Z drugiej strony, jeśli przejdziesz przez ten punkt, prawdopodobnie okaże się, że nawet nie potrzebujesz już „procesu”.
8. IMO od samego początku, twoi koledzy z drużyny nie nauczą się, jeśli nie zobaczą nic złego w swoich obecnych nawykach / praktykach. Więc może następnym krokiem w tym wszystkim jest znalezienie sposobu na zilustrowanie, podkreślenie problemów i uczynienie ich oczywistymi. W końcu nie piszemy czytelnego kodu, nie stosujemy zasad SOLID / DRY ani nie prowadzimy dokumentacji tylko dlatego, że daje nam to ciepłe i rozmyte wrażenie. Robimy to, ponieważ produkuje kod lepszej jakości i, szczerze mówiąc, przyspiesza nam kodowanie. Czy można to zmierzyć? Może właśnie tutaj pojawiają się wskaźniki oprogramowania?
9. Oto szalony pomysł i nie mam pojęcia, czy to rzeczywiście zadziała (może to być standardowa praktyka branżowa, a może zupełnie nieważne. Właśnie wymyśliłem to w ciągu ostatnich 24 godzin), ale mam wielką ochotę go przynieść do stołu, jak tylko rozpocznie się następny rok:
   • Wbrew opiniom wielu innych przedstaw pomysł autora / właściciela dla wszystkich plików źródłowych. Jak sugeruje Pragmatic Programmer , da to poczucie własności i odpowiedzialności jednej osobie, która będzie odpowiedzialna za kawałek kodu źródłowego. Nie oznacza to, że inni ludzie nie mogą modyfikować kodu, wszyscy pracujemy jako zespół, ale ostatecznie osoba, która jest właścicielem kodu, jest odpowiedzialna za sprawdzanie zmian.
   • Utwórz wyzwalacz repozytorium źródłowego, który monitoruje wszystkie zameldowania i wyszukuje te, które są poprawkami błędów. Uczyń to procesem, aby każda poprawka błędu miała identyfikator referencyjny bezpośrednio w opisie odprawy. Teraz napisz skrypt, który przeanalizuje listę plików, które zostały zmienione, i usunie „Autor” z bloku komentarza nagłówka pliku. Utwórz bazę danych SQL, która śledziłaby liczbę defektów zarejestrowanych dla każdego pliku / projektu / autora.
   • Kiedy masz wystarczającą liczbę statystyk, mam nadzieję, że zauważysz, że twój kod ma mniej wad / zmian niż niektóre inne kody. To są twarde dane, których możesz użyć. Jeśli pojedynczy projekt ma znacznie ponadprzeciętny wskaźnik defektów, przedstaw go jako kandydata do następnej próby oczyszczenia / refaktoryzacji w celu spłaty części długu technicznego.
   • Jeśli projekt lub plik ma znacznie powyżej średniej częstość defektów i ma jednego właściciela, porozmawiaj z tą osobą jeden na jednego. Zapytaj ich, bardzo uprzejmie, bez konfrontacji, co mogą zrobić, aby rozwiązać ten problem. Ponieważ są właścicielami, powinni wprowadzić zmiany, ale oferują wszelką pomoc z Twojej strony. Mamy nadzieję, że właściciel wyśledzi wiele przyczyn własnego kodu spaghetti i jak tylko poprosi o pomoc, wtedy zaczniesz działać i położysz SOLID.

Sugeruję, abyś porozmawiał ze swoim kierownikiem na temat problemu, ale prawie na pewno nie będzie chciał sprawdzać każdego zameldowania.

Zamiast tego sugeruję zasugerowanie zestawu testów jednostkowych / regresyjnych, które można podłączyć do SVN i uruchamiać przy każdym meldowaniu. Pomoże to przynajmniej uniknąć nieudanych kompilacji. Możesz stopniowo sugerować inne najlepsze praktyki.

Jeśli okaże się, że jest całkowicie niereceptyczny, może powinieneś przejść nad jego głową. Jeśli zdecydujesz się to zrobić, musisz zabrać ze sobą najlepszą grę. Zasadniczo będziesz kierować do kierownictwa, aby zostać zatrudnionym na wyższym poziomie, jeśli to zrobisz.