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
- 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.
- 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.
- 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.
- 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.
- Wiki działa cuda dla takich dokumentów.
- 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:
Niektóre są specyficzne dla PHP, ale odpowiedzi dotyczą wszystkich platform.