Jak przekonać programistów do przestrzegania podstawowych zasad

Jest kilka zasad, które muszę ciągle prosić programistów, aby przestrzegali ich bardzo często. Piszą kod, a jeśli to działa, zadanie jest właśnie dla nich wykonane. Najbardziej podstawowe zasady mogą być:

• Zatwierdzanie zmian
• Brak pisania problemów z modelem w widoku lub kontrolerach
• Unikaj twardego kodowania

Czy możesz mi powiedzieć o swoich doświadczeniach? Jak sobie z tym poradzisz?

Wszystkim pracownikom wiedzy należy postawić wyzwanie w celu wykonania dobrej jakości pracy. Jakość ucierpi, jeśli poczują, że zostały na nich nałożone arbitralne ograniczenia czasowe. Dlaczego nie stworzyć rzeczy, które są „wystarczająco dobre”, gdy wszyscy są zainteresowani spełnieniem specyfikacji i dotrzymaniem terminów?

Twoja lista skarg to objawy firmy, która nagradza jedynie osiąganie krótkoterminowych celów i nie chce kłaść nacisku na wysoką jakość. Prowadzisz pięciogwiazdkowy hotel lub przystanek dla ciężarówek?

Aby móc przestrzegać podstawowych zasad, muszą wiedzieć, jakie są reguły i muszą się z nimi zgodzić.

Sposób na poradzenie sobie z tym polega na wspólnym utworzeniu dokumentu zawierającego wytyczne kodowania, z którym każdy może się zgodzić. Nie próbuj narzucać im tego, bo to zrobisz.

Zbierz zespół i zacznij pracę nad wspólną definicją twoich podstawowych zasad!

Zrób to jako warsztat, w którym słychać wszystkie głosy. Timebox to, aby uniknąć niekończących się dyskusji. Próbujesz połączyć kilka umysłów, więc możesz ustawić scenę z pozytywną nutą, że wszyscy powinniście szanować i zachować otwarty umysł (pisanie kodu jest osobiste ...).

Te wytyczne powinny być zmieniane za każdym razem, gdy zespół czuje, że jest coś, co należy dodać lub wyjaśnić.

Jaka jest twoja rola? Jeśli jesteś tylko kolejnym programistą szczególnie zainteresowanym jakością kodu, prawdopodobnie nie masz uprawnień, aby skłonić ich do wysłuchania Ciebie, a być może powinieneś podburzyć te pomysły zarządowi, aby ustanowić standardy kodu, które powinny / muszą być śledził. Jeśli jesteś kierownikiem / kierownikiem zespołu / architektem i masz jakieś uprawnienia, możesz samodzielnie ustalić te praktyki. Opracuj dokument standardów i proces przeglądu kodu, aby wyeliminować te rzeczy.

To nie będzie magiczny przełącznik, który możesz włączyć; będzie to powolny proces i nigdy nie będzie w 100%. To i tak było moje doświadczenie.

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”.

Przegląd kodu. Akceptuj tylko dobrze napisany kod, który nie zawiera błędów.

Przynajmniej :

• Ułatw im podążanie za kodeliniami (narzędzia takie jak resharper, StyleCop). Jeśli jest to łatwiejsze, łatwiej jest je zastosować.

Poza tym wybierz, co działa w oparciu o twoją organizację, programistów i twoją rolę w zespole.

• Pozwól im regularnie naprawiać błędy i zmieniać żądania
• Połącz program z doświadczonym programistą
• Przegląd kodu w konstruktywny sposób
• Instrukcje dotyczące kodu
• Zacznij szkolenie, korzystaj z książek takich jak Code Complete i The pragmatic programmer.

Moją rolą jest Menedżer, ale jako mały zespół rozwijam się i wolę zarządzać jako trener.

Elektrody na krześle podłączone do parsera kodów zostały już wskazane, ale programiści nie wydają się bać. Strzelanie nie wydaje się dobrym podejściem, ponieważ oznacza utratę godnych aktywów.

Zajrzę do wszystkich tych narzędzi i pozostanę otwarty na wszelkie inne, które mi powiesz.

Istnieją 3 sposoby rozwiązania tego problemu:

1. Analiza statyczna kodu źródłowego w celu sprawdzenia problemów z konwencją kodowania. Używaj narzędzi takich jak cppcheck i te z gramatyki . Wikipedia ma dobrą listę: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis . Zazwyczaj większość systemów kontroli źródła ma haczyki, za pomocą których można sprawdzić takie problemy bezpośrednio podczas odprawy. W przypadku haków CVS zajrzyj pod ten link: http://goo.gl/F1gd2 . Nieprzestrzeganie oznacza nieudaną odprawę, a więcej niż 3 awarie oznaczają, że deweloper musi wyjaśnić się zespołowi.

2. Podczas samego procesu kodowania zgłaszaj problemy deweloperowi. Posiadanie niestandardowych skryptów zintegrowanych z wybranym IDE to świetny sposób na zrobienie tego. Sprawdź ten link: http://goo.gl/MM6c4

3. Postępuj zgodnie ze zwinnymi procesami i upewnij się, że przegląd kodu jest częścią sprintu

Oto mój trzyetapowy plan:

1. Odpal programistów
2. Zatrudnij inżynierów oprogramowania
3. ...
4. Zysk!

:RE

Z całą powagą, jeśli nie wierzą w nic innego jak pisanie kodu, potrzebujesz bardziej wszechstronnego zespołu. Programista, w którym pracowałem, używał różnych katalogów na komputerze jako jej CM. Walczyliśmy z ich programistą przez prawie rok (ponieważ zmiany wprowadzałyby błędy podczas kopiowania i wklejania starego kodu). W końcu po prostu ich zwolniliśmy.

1. Wskaż im, kiedy naruszają podstawowe zasady.
2. Poczekaj, aż wygenerują błędy, których po prostu nie mogą wyśledzić lub zostaną skonfrontowani z żądaniem funkcji, których po prostu nie mogą wdrożyć z powodu nieelastycznego kodu.
3. Przypomnij im o tym, co powiedziałeś wcześniej.
4. Niech przez jakiś czas utopią się we własnym gównie.
5. Poświęć trochę czasu na refaktoryzację danego kodu, izolowanie błędów / zapewnienie infrasturcutre w celu podłączenia nowej funkcjonalności. Poświęć trochę czasu na wyjaśnienie, co zrobiłeś.

Alternatywnie, najbardziej okrutne, ale bardzo przekonujące, co należy zrobić, to pozwolić im zachować wyjątkowo źle napisaną bazę kodów, biorąc pod uwagę napięty harmonogram. : D
A potem, dla odmiany, niech utrzymują dobrze napisaną bazę kodów, mając napięty harmonogram.

Zasadniczo niechęć do dostosowania określonych standardów oznacza brak doświadczenia w pracy zespołowej.

W końcu ludzie uczą się tylko na błędach. NIGDY nie naprawiaj problemów związanych z uporem kogoś innego. Jeśli jest to naprawdę niezbędne dla projektu (tj. Twoja firma zostanie pozwana, jeśli nie dostarczysz jej w ciągu N dni), to odłóż ją na bok od projektu.

Myślę, że programista nie zmieni swojego podejścia do wspomnianych przez ciebie problemów, dopóki nie uświadomią sobie, że te rzeczy przyniosą im korzyść. Spróbuj wyjaśnić im, dlaczego chcesz, aby robili te rzeczy. Jeszcze lepiej, pozwól im doświadczyć zalet.

Zatrudnij jednego profesjonalnego inżyniera oprogramowania. A potem strzelać najsłabiej. Następnie powoli zastępuj tych, którzy nie mogą adoptować. Posiadanie takich ludzi czasami przynosi więcej szkody niż zysku w dłuższej perspektywie.

Główną ideą tutaj jest, że profesjonalista zacznie wykonywać większość pracy, a zwolnienie innych nie zmniejszy cennego zasobu ludzkiego.

To trochę obrzydliwe, ale zostawiłem Code Complete w łazience na kilka miesięcy. Nie jestem pewien, czy był skuteczny, ale wtedy wydawało się, że to dobry pomysł.

Jakie są zatem konsekwencje nieprzestrzegania zasad i nagrody za przestrzeganie zasad? Jeśli odpowiedź jest taka sama - nic - powodzenia w uzyskaniu przyczepności. Proponuję podejście wielopoziomowe. Najpierw zbierz je razem i przedyskutuj, czy kupują zasady. Następnym krokiem jest włączenie ich do recenzji kodu. Możesz także spróbować marchewki i paluszków. Coś takiego, jak każdy, kto zostawi plik wyewidencjonowany w nocy, musi przynieść pączki na następne cotygodniowe spotkanie. Marchewką może być każdy, kto przestrzega zasad przez cały miesiąc, dostanie weekend w Vegas. Dla dwojga.

Lub zwolnij najgorszego przestępcę, a resztę potrenuj.

Spraw, aby cierpieli konsekwencje, których chcesz uniknąć, stosując te reguły, to jedyny sposób, w jaki naprawdę zrozumieją, dlaczego pytasz, np .: zrób mały kontrolowany bałagan, który muszą poprawić.

Jeśli ta załoga naprawdę ma problemy z sprawdzaniem zmian, przestrzeganiem rozdziału problemów i nieokreślaniem stałych magicznych, to zwolniłbym całą załogę i zastąpiłem ich prawdziwymi programistami ^1, którzy faktycznie dbają o swój statek tak szybko, jak to możliwe. Czy to pojedynczo, czy masowo, nie mogłem powiedzieć, ale ci żartownicy muszą odejść.

Kodowanie, które opisujesz, nadaje się do jednorazowych skryptów jednorazowych. Nie tak buduje się prawdziwą aplikację. Jeśli zarabiają jako profesjonalni programiści, to ich zadaniem jest wiedzieć tego rodzaju rzeczy.

¹ Jest to często używane jako żart dla wyimaginowanych ludzi, którzy piszą swój kod bezpośrednio w formacie binarnym lub coś równie niedorzecznego. Nie żartuję. Jestem dość początkującym programistą i nie musiałbym mówić o tych rzeczach, ponieważ zależy mi na moim rzemiośle. To nie są prawdziwi programiści, z którymi masz do czynienia.

Zadaniem menedżera nie jest bycie przyjacielem pracownika, czasem trzeba być złym facetem. Egzekwowanie standardów kodowania i zatwierdzeń, odmowa przestrzegania proscibed architektury, niestosowanie zalecanych narzędzi itp. To czasy, w których trzeba być niepopularnym.

Wyraźnie wyrażaj zasady. Dokonuj formalnych recenzji kodu i sprawdź, czy przestrzegane są zasady. Nie pozwól im przejść do innego zadania, dopóki wszystkie problemy z przeglądu kodu nie zostaną rozstrzygnięte.

Jeśli zasady dotyczą nie zatwierdzania kodu, wymaga to pisemnego ostrzeżenia, jeśli nie mogą tego zrobić, gdy zostanie o to poproszony. Jeśli nie popełniają kodu, według ciebie nie napisali żadnego.

Jeśli nie poprawią się po uzyskaniu rozsądnej szansy na ulepszenie, zwolnij je. Nieprofesjonalni programiści przeszkadzają zespołowi bez względu na to, jaki kod piszą. Wpływają na innych z powodu braku profesjonalizmu i nie można ich tolerować. W żadnym wypadku nie są dobrymi ludźmi do zachowania. Dobrzy programiści zatwierdzają swój kod, dobrzy programiści podążają za decyzjami architektonicznymi, nawet jeśli się z nimi nie zgadzają, a dobrzy programiści nie kodują na stałe. Nie pozbędziesz się niczego poza bólami głowy, pozbywając się kowbojskich programistów.