Jak radzić sobie z różnymi stylami programowania w zespole?

Mamy mały zespół deweloperów (tylko 3 programistów), a ostatnio mamy nowego członka zespołu. Chociaż jest inteligentnym programistą, jego styl kodowania jest zupełnie inny niż nasz. Nasza istniejąca baza kodu zawiera głównie czytelny, czysty i łatwy do utrzymania kod, ale nowy członek zespołu szybko zmienia wiele plików, wprowadza brzydkie włamania i skróty, używa definicji w dowolnym miejscu, dodaje funkcje w niewłaściwych miejscach itp.

Moje pytanie brzmi: czy inni doświadczyli już takiej sytuacji i czy ktoś ma wskazówki, jak z nim rozmawiać.

Współpracuję z zespołem, który powiększył się z 2 programistów do 10 w niecały rok. Byłem numerem 3 i jako pierwszy podniosłem kwestię standardów kodowania. Dwaj oryginalni programiści pracowali obok siebie przez kilka lat i przyjęli wspólny standard, który wydawał mi się obcy. Mieliśmy dokładnie te same problemy, które opisujesz.

To, co zrobiliśmy, to:

Badaj standardy kodowania

Spędziliśmy kilka dni sprawdzając ustanowione projekty open source. Wiedzieliśmy, że zespół szybko się powiększy i szukaliśmy prawdziwych rozwiązań opartych na prawdziwych projektach, a nie ogólnych wytycznych. Nie dbaliśmy również o optymalne standardy kodowania, ale o zestaw zasad i wytycznych, które miałyby sens i nie wymagałyby refaktoryzacji całej naszej bazy kodu. Szukaliśmy hackowania standardów kodowania, jeśli chcesz.

Nasza trójka zdecydowała, że ​​najlepszymi standardami kodowania dla ustalonego projektu PHP są te, za którymi podąża Zend Framework. Na szczęście ludzie Zend Framework dostarczają bardzo obszerny dokument standardów kodowania .

Tworzenie własnych standardów kodowania

Oczywiście zastosowanie w naszym projekcie standardów kodowania innego projektu, ponieważ nie ma to sensu. Używamy dokumentu Zend Framework jako szablonu:

• Najpierw usunęliśmy wszystko, co nie dotyczyło naszego projektu
• Następnie zmieniliśmy wszystko, co postrzegaliśmy jako kwestię stylu na nasz styl
• I w końcu wszystko spisaliśmy

Mieliśmy więc dość duży dokument, przechowywany na naszej fantazyjnej wiki , była to miła lektura, uzgodniona przez nas wszystkich. I całkowicie bezużyteczne samo w sobie.

Pozostając wiernymi naszej obietnicy

Nasza baza kodów w tym czasie wynosiła około 1 * 10 ^ 6 sloc. Wiedzieliśmy, że odkąd przyjęliśmy formalne standardy kodowania, musieliśmy zacząć refaktoryzować nasz kod, ale w tym czasie byliśmy zmuszeni do innych problemów. Więc postanowiliśmy po prostu zrefaktoryzować nasze podstawowe biblioteki, zaledwie 5 * 10 ^ 3 sloc.

Przypisaliśmy jednego z nas, aby był mistrzem standardów kodowania (użyliśmy wulgaryzmu lokalnego zamiast mistrza ) odpowiedzialnym za sprawdzanie i egzekwowanie standardów. Rolę przetwarzamy co kilka sprintów. Byłem pierwszy i było to dużo pracy, ponieważ musiałem monitorować prawie każde zatwierdzenie.

Podczas mojej kadencji przeprowadziliśmy kilka nowych dyskusji i małe dodatki do oryginalnego dokumentu, a na koniec mieliśmy dość stabilny dokument. Zmieniamy to od czasu do czasu, ale większość tych zmian dotyczy nowych funkcji języka, ponieważ PHP 5.3 było ważnym wydaniem z wyjątkiem nazwy.

Radzenie sobie z nowym facetem

Kiedy pojawił się kolejny nowy facet, nadszedł czas, aby przetestować nasze standardy kodowania. Po krótkim wprowadzeniu do naszej bazy kodów poprosiliśmy go o ocenę naszego dokumentu standardów kodowania. Niemal płakał. Wyglądało na to, że zrobił wszystko inaczej.

Jako że byłem wówczas mistrzem standardów kodowania, do mnie należało ocena jego wkładu i odpowiednia korekta dokumentu. Jego propozycje to:

• Kwestie stylu osobistego (odrzucone na krótko)
• Standardy, które miały sens dla jego środowiska Java, ale nie tak bardzo w PHP (odrzucono)
• Konwencje, które przeprowadził po krótkiej prezentacji z PHP (niektóre zostały odrzucone, ale wiele z nich okazało się popularnymi konwencjami, o których nigdy nie myśleliśmy ani nie dowiedzieliśmy się w naszych początkowych badaniach)

Przez następne kilka tygodni wyznaczono mu proste zadanie: zaktualizować kilka części naszej bazy kodów zgodnie ze standardami. Musiałem starannie wybrać te części na podstawie kilku zasad:

• Kod powinien być względnie łatwy dla kogoś, kto nie zna naszej bazy kodu (i ogólnie PHP)
• Kod powinien dotyczyć tego, do czego został zatrudniony

Monitorowałem jego proces, a on wykonał kawał dobrej roboty. Zidentyfikowaliśmy kilka części kodu, których nie można było dopasować do naszego dokumentu, i odpowiednio zmieniliśmy (kod i / lub standardy, w zależności od tego, które mają większy sens)

A potem przybył kolejny nowy facet. Powtórzyliśmy ten proces (tym razem inny master) i znów zadziałał. I ponownie.

Podsumowując

1. Utwórz dokument standardów kodowania, ale upewnij się, że standardy nie są wyłącznie własne, ale odzwierciedlają wspólne standardy w szerszej społeczności Twojej platformy.
2. Przypisz podobną rolę naszemu mistrzowi standardów kodowania. Ktoś do monitorowania co najmniej nowego kodu, a zwłaszcza nowego kodu od nowych członków. Przetwarzaj rolę, ponieważ jest bardzo nudna.
3. Zawsze oceniaj dane wejściowe od nowego członka. Zawsze popraw swoje standardy, jeśli ma to sens. Twój dokument standardów kodowania powinien ewoluować, ale powoli. Nie chcesz ponownie refaktoryzować bazy kodu przy każdej iteracji.
4. Każdemu nowemu członkowi poświęć trochę czasu na naukę i dostosowanie się do twoich standardów i konwencji. Ucz się, wykonując czynności najlepiej w takich sytuacjach.
5. Wiki działa cuda dla takich dokumentów.
6. Recenzje kodu działają cuda w każdej sytuacji!

W pewnym momencie procesu zasugerowano użycie haka przed zatwierdzeniem do zautomatyzowania sprawdzania standardów. Zdecydowaliśmy się na to z różnych powodów, na StackOverflow jest kilka interesujących dyskusji na ten temat:

• Automatyczne formatowanie kodu SVN przy odprawie?
• Kontrola wersji i formatowanie kodowania
• PHP codeniffer (phpcs) - jak zezwolić na zastąpienie, gdy jest używany jako część haka wstępnego zatwierdzania SVN?
• Hak SVN poprzedzający zatwierdzenie, który ma być wyzwalany dla określonego folderu
• Wdrażanie standardów kodowania PHP

Niektóre są specyficzne dla PHP, ale odpowiedzi dotyczą wszystkich platform.

Tak, doświadczyłem tego wcześniej. Podczas pracy w zespole członkowie zespołu muszą uzgodnić pewne zasady i konwencje, w tym styl.

Powinieneś usiąść razem ze swoim zespołem i opracować zbiór zasad, standardów kodowania , do których przestrzegania byłby potrzebny każdy element zameldowanego kodu.

Najprawdopodobniej podstawą twojego zestawu reguł, przynajmniej stylu, będzie istniejący kod. Po zakończeniu wszyscy muszą się zastosować i należy to sprawdzić w ramach przeglądu kodu . Kod niezgodny ze standardami nie powinien być dopuszczany do odprawy.

Nawiasem mówiąc, nie musi to być demokratyczny głos, jest to jedna z rzeczy, w których lider zespołu może faktycznie sprawować władzę. Ale powiedziawszy to, nie sądzę, że można narzucić standardy, które większość zespołów odrzuca. Państwo może narzucać norm, które jedna osoba, zwłaszcza nowy, odrzuca.

Co do tego, jak z nim rozmawiać ... Każdy doświadczony programista wie, że każde miejsce i zespół ma swoje własne konwencje i styl, których należy przestrzegać. Możesz mu powiedzieć, że chętnie zasugeruje ulepszenia, ale musi przestrzegać zasad zespołu i nie powinien zmieniać stylu istniejącego kodu, ale powinien używać tego samego stylu podczas dodawania nowego kodu.

Możesz także powiedzieć tej osobie (jeśli jesteś kierownikiem lub porozmawiać o tym ze swoim menedżerem), aby nie robił rzeczy, które uważasz za nieodpowiednie (wspomniałeś o definicjach, porządku, włamaniach i skrótach itp.).

1. Ktoś dowodzi - musi tak postępować.
2. Jeśli styl kodowania jest tak ważny, dlaczego nie zostało to wyjaśnione tej osobie i poinformuj ją, że nie będą mieli dostępu do żadnego kodu, dopóki nie nauczą się zasad.
3. Przegląd kodu - najwyraźniej go nie masz lub jest bardzo słaby. Zobacz nr 1.

W procesie rekrutacyjnym zwróć uwagę, że przestrzeganie przyjętych stylów kodowania jest warunkiem zatrudnienia. Co teraz robisz tym, którzy nie przestrzegają zasad? Zacznij od usunięcia ich dostępu do kodu na żywo, dopóki nie wejdą do programu.

.

Oto, co można zrobić:

1. Napisz dokument wyjaśniający wymagany styl kodowania i spraw, aby wszyscy w zespole się go nauczyli. Zbierz informacje od każdego członka zespołu.
2. dzielić zadania w taki sposób, aby każdy członek zespołu był odpowiedzialny za swój kawałek i mógł decydować o konwencjach tej części kodu. Jeśli zostaną znalezione jakiekolwiek problemy, ktokolwiek to napisał, naprawi je.
3. dodaj automatyczne narzędzie do kontroli wersji, które naprawia wcięcia i inne rzeczy za każdym razem, gdy kod jest przypisany do kontroli wersji
4. Różni programiści zawsze mają inny styl programowania, a później zmiana może być trudna. Najlepszym sposobem, aby sobie z tym poradzić, jest dzielenie się informacjami między członkami zespołu, aby każdy nauczył się, jakiego stylu ludzie używają. Jeśli masz członka zespołu, który pisze inny kod, twoi obecni członkowie zespołu mają szansę nauczyć się nowego stylu.
5. Jedną dobrą sztuczką jest nigdy nie modyfikować istniejącego kodu. Zamiast modyfikować kod, napisz nowy kod, zastępując puste wiersze nowym kodem. A gdy kod będzie gotowy, wprowadź tylko najmniejsze modyfikacje do istniejącego systemu, aby użyć nowego kodu. Pozwala to uniknąć poprawiania istniejącego kodu, prawdopodobnie psując to, co już działało dobrze.

Oto, czego należy unikać:

1. decydowanie, że czyjś kod jest lepszy lub gorszy niż inni członkowie zespołu. Po prostu tak nie działa - każdy zna pewien podzbiór języka wystarczająco dobrze, aby używać go w kodzie. Każdy programista wybrał inny podzbiór do nauki i jeśli nie nauczyli się tego razem, będzie wyglądać inaczej.
2. Zmiana sposobu pisania kodu. Zmuszając ludzi do pisania nieznanego stylu, dostajesz tylko dużą liczbę błędów w kodzie. Ludzie po prostu nie znają wystarczająco dużo szczegółów, z których korzystają za pierwszym razem. Programiści zawsze wybierają podzbiór języka i używają go osobno. Jeśli programiści napisali tysiące wierszy kodu wypełnionego gotos, to gotos dostarczy ci kod, który zawiera najmniej błędów.
3. Nie powinieneś również myśleć, że twoja istniejąca baza kodu jest ładna, czysta i łatwa w utrzymaniu. Zawsze jest coś do poprawienia. Ale także każda zmiana zaciera oryginalny pomysł na projekt, który został do niego napisany. Postaraj się napisać idealny kod za pierwszym razem, aby zmiany nie były potrzebne później. (nowy facet nie musiałby „łamać” twojego idealnego kodu, gdyby był zrobiony poprawnie za pierwszym razem)

Nasza obecna baza kodu zawiera głównie czytelny, czysty i łatwy do utrzymania kod

Nauczyłem się przez lata, że ​​czytelność zależy od obserwatora. Widziałem wiele przypadków, w których czyjś styl kodowania przez kurczaki jest uzasadniony jako „czytelny”, i widziałem doskonale rozsądnych ludzi, którzy spierają się o to, które style kodowania są najbardziej „czytelne”. Może ten facet nie uważa twojego stylu za czytelny?

To powiedziawszy, nowy facet powinien spełniać twoje standardy, a nie na odwrót.

Rozważ użycie żądań pobrania nowego kodu do repozytorium. Daje to wygodne miejsce do przeglądu kodu. Kod, który nie przejdzie przeglądu kodu, nie jest scalany z repozytorium, dopóki nie zostanie poprawiony.

Uważaj tylko, aby żądania ściągania nie były zbyt duże. Z mojego doświadczenia wynika, że ​​nie powinny one być większe niż od pół dnia do maksymalnie dwóch dni, w przeciwnym razie wystąpi zbyt wiele konfliktów scalania.

Internetowe systemy vcs, takie jak bitbucket lub github, obsługują tę funkcję. Jeśli wolisz podejście zakładowe, wydaje się, że najlepszy jest obecnie zakład.

Istnieje prosta zasada, którą możesz przestrzegać: Jeśli zmodyfikujesz plik za pomocą kodu, użyjesz standardu kodowania zastosowanego w tym pliku. Jeśli tworzysz nowy plik, korzystasz z dowolnego dobrego standardu kodowania. (Plus: Jeśli Twój kompilator może wyświetlać ostrzeżenia, włącz wszystkie uzasadnione ostrzeżenia, włącz ostrzeżenia = błąd, jeśli to możliwe, i nie zezwalaj na żaden kod z ostrzeżeniami. Plus: Jeśli używasz narzędzi, które wprowadzają hurtowe zmiany w pliku, takie jak zmiana tabulatory do spacji itp., NIE używaj ich).

Powodem, dla którego istnieją ogromne argumenty na temat standardów kodowania, jest to, że jeden standard nie jest lepszy ani gorszy od drugiego (zwykle), ale po prostu inny. Jedyną naprawdę złą rzeczą jest mieszanie stylów kodowania.

Oczywiście oczekuję, że każdy porządny programista może pisać kod zgodnie z dowolnym standardem kodowania, bez względu na to, czy woli ten konkretny standard, czy nie.

Z drugiej strony istnieją standardy jakości. Nigdy nie akceptuj kodu, który nie spełnia twoich standardów jakości.