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óż:
- 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 ...
- 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.
- 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?
- 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.
- 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 .
- 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.
- 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”.
- 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?
- 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.