Musi to być rozsądne połączenie wszystkich dotychczasowych odpowiedzi. Ostatecznie, kiedy mówisz o grupie inteligentnych ludzi (programistów), musisz podać im powody, dla których zachowanie jest ważne i dać im wystarczającą kontrolę nad tym , jak to zachowanie jest wdrażane, aby zainwestowali w robienie tego dobrze. Mandaty z góry są na ogół luźne w stosunku do inteligentnych ludzi, ponieważ jeśli nie zgodzili się, że problem jest problemem, prawdopodobnie spędzą więcej czasu na pracy nad mandatem niż na przestrzeganiu reguły.
Oto kilka moich taktyk:
Zatwierdzanie zmian:
Po pierwsze, zespół musi ustalić, kiedy i co popełnić. Absolutnie niezbędna jest konfiguracja kompilacji, która ma sens, aby ludzie nie powstrzymywali się tylko dlatego, że nie wiedzą, gdzie coś położyć. A konsensus co do tego, kiedy / jak często się zameldować. „Nie psuj kompilacji” jest oczywistą dobrą zasadą, ale jak to się sprawdza i komu się o tym mówi? Innym punktem odniesienia jest „nie jest to zrobione, jeśli nie zostanie zarejestrowane”.
Większość programistów, których znam, chętnie sprawdza kod IF:
- Proces odprawy jest łatwy
- Proces synchronizacji jest łatwy (uwzględnianie zmian od innych programistów)
- Przeglądanie zmian i przechodzenie między wersjami jest łatwe
Jedną z rzeczy, które zauważyłem ostatnio, było to, że meldunki stały się częstsze i mniej bolesne, gdy przechodziliśmy do nowego narzędzia CM. Nasz zespół jest pionierem Rational Team Concert, który wcześniej używał Clearcase. Nie chcę reklamować narzędzi, ale nowa (dla mnie) fala strumieniowych czeków z dużą ilością małych, szybkich połączeń sprawia, że znacznie bardziej kuszące jest wczesne i częste sprawdzanie.
Pozwalanie programistom odpowiedzialnym za eliminację bólu CM generalnie zwiększa ilość meldunków.
Przestrzeganie architektury - brak pisania problemów z modelami w widokach i kontrolerach
Umieszczam to w ogólnej grupie „poprawnie wykonuj architekturę”. Zgadzam się z kimkolwiek, kto powiedział recenzentom - presja rówieśników jest do tego świetna. Jednym ze sposobów, w jaki ogólnie widzę, są ludzie, którzy przychodzą do najlepszych praktyk w tej dziedzinie, kiedy ich rówieśnicy pytają ich, dlaczego zrobili to w drugą stronę (nie tak dobrze). Zasadniczo pytanie „dlaczego” poprowadzi ludzi na ścieżkę uświadomienia sobie, dlaczego powinni to zrobić inaczej. Kiedy ludzie mają dobrze rozumiany powód najlepszej praktyki, o wiele łatwiej jest ją zastosować.
Ponadto, jeśli istnieje jakaś formalność łącząca osobę z decyzją, wówczas łatwiej jest przypisywać błędy w tym obszarze ... więc jeśli dana osoba jest odpowiedzialna za naprawianie błędów w obszarze wadliwego projektu, potrzeba dostać coś wcześniej mogą przejść do czegoś nowego, a ekscytująca może być dużym czynnikiem motywującym.
Unikaj twardego kodowania
Zacznę od jasnych standardów kodowania i włączenia recenzji standardu kodowania do recenzji. Kodowanie na stałe jest jedną z tych rzeczy, które mogą łatwo być polem wyboru w porządku recenzji.
Obawiam się, że takie rzeczy są jedyną rzeczą, w której widziałem, jak rolą zespołu jest egzekwowanie reguły. W zespołach, które prowadzę, na ogół nie pozwalamy komuś przejść, dopóki nie naprawią komentarzy z recenzji swojego kodu. A „brak twardego kodu” jest częstym komentarzem recenzenta.
Ogólnie
Przy prawie każdej najlepszej praktyce, myślę, że musisz wybrać swoje bitwy. Żaden zespół nie stanie się absolutnie idealny. Ale możesz mieć oko na swoje główne punkty bólu i zacząć walczyć z nimi w grupach. Myślę, że rolą lidera staje się faktyczne zrozumienie, co jest bolesne dla zespołu a irytujące dziwactwo konkretnej osoby.
Jeśli twój zespół nie chce wykonać określonej najlepszej praktyki, myślę, że pierwsze pytanie musi brzmieć „ile szkód to powoduje?” jeśli odpowiedź jest „minimalna”, to prawdopodobnie nie jest to warte czasu. Niektóre najlepsze praktyki są najbardziej odpowiednie dla określonych rodzajów systemów - chociaż ogólnie są dobre, mogą nie być warte bitwy o systemy, w których praktyka nie jest częstym zjawiskiem lub większą częścią systemu.
Jeśli odpowiedź na „ile damange?” to „DUŻO !!!”, możesz zacząć budować argumenty za pokazaniem zespołowi, że cały ten ból i cierpienie można usunąć, ustalając ten jeden punkt rozluźnienia w najlepszych praktykach. Większość ludzi chętnie unika bólu i cierpienia, co zmienia dialog z „rób to, bo ci to powiedziałem”, na „zdecydowaliśmy się to zrobić, bo jest lepiej”.