Obsługa standardów kodowania w pracy (nie jestem szefem)

Pracuję w małym zespole, około 10 deweloperów. W ogóle nie mamy standardów kodowania. Są pewne rzeczy, które stały się normą, ale niektóre sposoby robienia rzeczy są całkowicie odmienne. Mój duży to wcięcie. Niektóre używają tabulatorów, niektóre używają spacji, niektóre używają innej liczby spacji, co stwarza ogromny problem. Często łączę się z konfliktami, gdy łączę się, ponieważ ktoś użył ich IDE do automatycznego formatowania, a oni używają innego znaku do wcięcia niż ja. Nie obchodzi mnie, z którego korzystamy. Chcę, żebyśmy wszyscy korzystali z tego samego.

Albo otworzę plik, a niektóre wiersze mają nawiasy klamrowe w tym samym wierszu co warunek, podczas gdy inne mają je w następnym wierszu. Znów nie mam nic przeciwko temu, o ile wszystkie są takie same.

Podniosłem kwestię standardów do mojego bezpośredniego menedżera, jeden na jednego i na spotkaniach grupowych, i nie jest on tym zbytnio zaniepokojony (jest kilku innych, którzy podzielają ten sam pogląd jak ja). Podniosłem swoją szczególną troskę o znaki wcięcia, a on pomyślał, że lepszym rozwiązaniem byłoby „stworzyć jakiś skrypt, który mógłby przekonwertować to wszystko, kiedy wypychamy / ściągamy z repozytorium”. Podejrzewam, że nie chce się zmieniać, a to rozwiązanie wydaje się zbyt skomplikowane i podatne na problemy związane z utrzymaniem na późniejszym etapie (dotyczy to tylko jednego przejawu większego problemu).

Czy któryś z was napotkał podobną sytuację w pracy? Jeśli tak, jak sobie z tym poradziłeś? Jakie byłyby dobre punkty, aby pomóc sprzedać mojemu szefowi według standardów? Czy dobrym pomysłem byłoby rozpoczęcie oddolnego ruchu w celu stworzenia standardów kodowania wśród tych z nas, którzy są zainteresowani? Czy jestem zbyt szczególny, czy powinienem po prostu odpuścić?

Dziękuję wszystkim za poświęcony czas.

Uwaga: Dziękujemy wszystkim za wspaniałe opinie! Mówiąc wprost, nie chcę dyktować jednego stylu, aby rządzić nimi wszystkimi. Jestem skłonny przyznać się do preferowanego przeze mnie sposobu robienia czegoś na korzyść tego, co najbardziej odpowiada każdemu. Chcę konsekwencji i chcę, aby była to demokracja. Chcę, aby była to decyzja grupowa, na którą wszyscy się zgadzają. To prawda, że ​​nie wszyscy zdążą, ale mam nadzieję, że wszyscy będą wystarczająco dojrzali, aby pójść na kompromis dla poprawy grupy.

Uwaga 2: Niektóre osoby są przyłapane na dwóch przykładach, które podałem powyżej. Bardziej chodzi mi o sedno sprawy. Przejawia się to wieloma przykładami: konwencje nazewnictwa, ogromne funkcje, które powinny zostać rozbite, jeśli coś pójdzie w użyciu lub usłudze, jeśli coś będzie stałe lub wstrzyknięte, czy wszyscy powinniśmy używać różnych wersji zależności lub tego samego, jeśli W tym przypadku należy użyć interfejsu, jak skonfigurować testy jednostkowe, co należy przetestować, (specyficzne dla Javy), czy powinniśmy używać adnotacji lub konfiguracji zewnętrznej. Mógłbym kontynuować.

Współpracownik i ja mieliśmy podobny problem w naszym zespole, kiedy po raz pierwszy dołączyliśmy (najpierw dołączyłem do zespołu, on dołączył około rok później). Nie było prawdziwych standardów kodu. Jesteśmy sklepem MS i nawet standardy kodowania MS nie były używane. Postanowiliśmy dać przykład. Usiedliśmy razem i opracowaliśmy dokument, który zawiera wszystkie nasze standardy: standardy IDE, standardy nazewnictwa, wszystko, co możemy wymyślić. Potem on i ja uzgodniliśmy, że będziemy ściśle przestrzegać tego standardu. Wysłałem e-mail do zespołu (od nas obu) i powiadomiłem ich, że stwierdziliśmy brak i zamierzamy rozwiązać ten problem za pomocą naszego dokumentu. Zaprosiliśmy krytykę, pomysły, komentarze, opinie. Otrzymaliśmy bardzo niewiele informacji zwrotnych i tylko niewielką liczbę odpowiedzi. On i ja natychmiast zaczęliśmy stosować standardy, a kiedy włączyliśmy młodszych programistów do naszych projektów, wprowadziliśmy ich do standardu i zaczęli go używać. Mamy kilku potencjalnych klientów, którzy początkowo byli niechętni, ale powoli zaczęliśmy używać standardu do wielu rzeczy.

Odkryliśmy, że wielu młodszych programistów rozpoznało ten sam problem, ale czekało, aż ktoś inny podejmie decyzję i podejmie decyzję. Kiedy był już plan do naśladowania, wielu chętnie go przyjęło. Twarde orzechy do zgryzienia to te, które odmawiają kodowania w jakikolwiek inny sposób, i na dłuższą metę zwykle same się zakodują.

Jeśli chcesz standardów, wytycz ścieżkę. Wymyśl sugerowaną listę standardów, które Twoim zdaniem przyniosą korzyści Twojemu zespołowi. Prześlij go do użytkowników i potencjalnych klientów, aby uzyskać informacje zwrotne. Jestem pewien, że inni ludzie w twoim zespole mają podobne pomysły, ale prawdopodobnie nie mają ochoty nic z tym zrobić. Jak powiedział Gandhi: „Musisz być zmianą, którą chcesz zobaczyć na świecie”.

Normy nie powinny być czymś określonym i egzekwowanym przez kierownika. Zespół jako całość powinien zgodzić się na standardy. Jeśli nie będą w stanie uzgodnić wspólnego zestawu standardów, nakłonienie menedżera do narzucenia im standardów zakończy się niepowodzeniem.

Ty i inni, którzy się z tobą zgadzacie, powinniście dawać przykład. Zacznij korzystać z tych samych standardów kodowania, publikuj je i promuj wśród reszty zespołu oraz zaproś opinie na temat ich ulepszenia.

Oto ważna kwestia, gdy staramy się promować standardy: upewnij się, że nie skupiasz się na znalezieniu najlepszego sposobu, ale raczej na znalezieniu spójnego sposobu robienia rzeczy. Chociaż niektórzy ludzie mogą się nie zgodzić, nie ma jednego prawdziwego stylu nawiasów klamrowych, żadnego prawdziwego stylu komentowania itp. To, co czyni kod łatwiejszym do odczytania (a zatem i łatwiejszym w utrzymaniu), jest spójnym stylem, bez względu na to, co to jest.

Czy możesz pokazać jakieś dowody czasu, który zmarnowałeś z powodu problemów, które powoduje?

Jeśli spędzasz dużo czasu na rozwiązywaniu tych problemów lub powoduje to błędy, które wymagają czasu, aby je naprawić, to jest to koszt, który możesz drastycznie zmniejszyć, przyjmując standardy kodowania.

Dlatego przechowuj dzienniki napotkanych problemów i czas potrzebny na ich rozwiązanie - zarówno dla ciebie, jak i (tam, gdzie jesteś ich świadomy) swoich kolegów.

Następnie, gdy masz rozsądną ilość danych, przedstaw je swoim kolegom. Powinny widzieć korzyści wynikające z przyjęcia normy. Jeśli nie, pokaż dane swojemu szefowi i jego szefowi. Pokaż, że dzięki standardom kodowania możesz zaoszczędzić pieniądze swojej firmy i powinni cię wspierać w ich adaptacji.

W twojej konkretnej sytuacji uważam, że rozwiązanie twojego szefa jest dobre. Nikt nie musi zmieniać tego, co robili przez całą swoją karierę, i to jest w porządku, ponieważ fragmenty stylu kodu ignorowane przez kompilator nie mają znaczenia, dopóki kod jest czytelny. Gdyby każdy zrobił autoformatowanie do swojego stylu podczas sprawdzania i autoformatowanie do standardowego stylu podczas sprawdzania, wszystko byłoby dobrze. (Niestety zasugerowałem, że tam, gdzie pracuję, i było to sprzeczne ze względu na to, że programista nie będzie już pisał tego samego dokładnego kodu, co widzi serwer ciągłej integracji).

Myślę, że standardy kodowania są dobre, gdy są stosowane w miejscach, w których ma to rzeczywistą różnicę w jakości kodu: na przykład małe metody, klasy, które mają jedną jasno określoną odpowiedzialność, przydatne i dokładne komentowanie trudniejszych bitów itp. Niestety, te aspekty są trudniejsze do automatycznego sprawdzenia, ale ma to zasadnicze znaczenie dla rozwoju oprogramowania. Wszystko, co możesz naprawdę zrobić, to nauczyć innych dobrych praktyk i nauczyć się czytać kod z nawiasami w niewłaściwym wierszu.

Odnośnie standardów kodowania: Będę wchodził na pokład z prawie wszystkimi innymi, mówiąc, że standardy kodowania są „dobrą rzeczą” (w porównaniu do braku standardów).

Nie daj się jednak ponieść emocjom. Pracowałem nad niektórymi projektami, które dyktowały konkretny styl wcięcia, aż do liczby znaków (a kiedy projekty posuwają się tak daleko, nieuchronnie wybierają coś głupiego, jak 8 wcięcia przestrzeni). Nie przejmuj się małymi rzeczami.

Proste rozwiązanie: Daj programistom ograniczony zestaw opcji nawiasów klamrowych i wcięć, ale podyktuj, że styl nawiasów klamrowych i wcięcia muszą być spójne w całym module. (Chcesz, aby foo.h i foo.cpp działały w tym samym stylu, prawda?) Opiekunowie muszą dostosować się do istniejącego stylu; nie mogą przepisać modułu, aby pasował do ich kapryśnego stylu. Wiele stylów w module jest po prostu mylące i jest oznaką niechlujstwa. Kiedy widzę te bzdury, zastanawiam się, co jeszcze jest nie tak.

Możesz także pomyśleć o zablokowaniu zakładek do wcięć w zapisanej zawartości pliku . Większość IDE / redaktorów wykonuje rozsądną pracę tłumacząc tabulatory wprowadzane przez użytkownika na spacje, a większość ma opcje automatycznego tłumaczenia. Wiele z nich robi kiepską robotę, gdy plik już zawiera tabulatory, zwłaszcza mieszany zestaw tabulatorów i spacji.

To powiedziawszy, myślę, że możesz mieć głębszy problem w swoim projekcie. Wspomniałeś o problemach z scalaniem. Jeśli musisz dużo scalić, może to świadczyć o złym podziale projektu. Tak jak zbyt wielu kucharzy psuje bulion, zbyt wielu programistów działających na tym samym pliku psuje projekt. Dlaczego każdy z Joe, Susie i ty dotykasz foo.cpp?

Jest to jeden z obszarów, w których prowadzone są badania. Zasadniczo główne pytanie brzmi, czy przeprowadzasz recenzje kodu. Przeglądy kodu są bez wątpienia najbardziej skutecznym sposobem na poprawę jakości kodu. (Źródło: Software Engineering Institute, CMU). Jest to z pewnością bardziej wydajne niż dodatkowy tester.

Teraz recenzje kodu korzystają ze wspólnego standardu kodowania, ponieważ ułatwia to czytanie kodu innych osób. To daje ci dwuetapowy argument na rzecz wprowadzenia standardów kodowania: w końcu sprawia, że ​​taniej jest produkować dobry kod.

Ponieważ jest już „kilku innych”, którzy są z tobą w tej sprawie, proponuję improwizowane spotkanie. Zaproś wszystkich twórców, poświęć chwilę i dowiedz się, jakie rzeczy przeszkadzają Tobie i Twoim współpracownikom z dnia na dzień. Nie próbuj na początku szukać konkretnych rozwiązań, po prostu dowiedz się, co wymaga zmiany w sposobie pisania kodu.

Następnie sprawdź, czy wszyscy możecie zgodzić się na kilka podstawowych pojęć. Sugestia użycia tego samego stylu w każdym module, którą przedstawił @David Hammen, to dobry początek i myślę, że większość programistów chętnie się na to zgodzi.

Jeśli, kiedy już to zrobisz, poczujesz, że wszyscy możecie zgodzić się na podstawowy styl pisania nowego kodu, to dobry dodatek. Skoncentruj się na rzeczach, które faktycznie wpływają na łatwość utrzymania; problemy z nazewnictwem byłyby wysoko na mojej osobistej liście, ponieważ jeśli masz pół tuzina różnych stylów nazewnictwa w jednym produkcie o jakiejkolwiek znaczącej złożoności, bardzo szybko stanie się to problemem, ale ponownie skup się na tym, co Ty i Twój zespół uważacie za ważne . Przygotuj krótki dokument, który każdy może przynajmniej zgodzić się przestrzegać (nawet jeśli sam może mieć inny styl zwierzaka) i wyślij go pocztą do wszystkich członków zespołu. Zrób to „żywy” dokument, upewnij się, aby aktualizować go z czasem, ale pamiętaj, aby nie uczynić go zbyt sztywny i konkretne.

O ile twój szef nie jest zaangażowany w pisanie kodu, nie powinien zbytnio martwić się o to, jaki dokładnie styl zostanie przyjęty (pod warunkiem, że skupia się on na czytelności i łatwości konserwacji), ale powinien być w stanie zobaczyć korzyści każdego w zespole według wspólnego stylu podczas pisania kodu.

Niektóre rzeczy są bolesne. Najbardziej bolesne jest IDE, które automatycznie formatuje kod w połączeniu z programistami, którzy konfigurują swoje IDE na różne sposoby. Za każdym razem, gdy porównujesz kod, masz sto zmian po tym, jak ktoś z różnymi ustawieniami dokonał edycji kodu. To niedopuszczalne. Tutaj musisz uderzyć wszystkich głowami w całość, uzgodnić zestaw ustawień i odrzucić wszelkie kontrole przez osoby używające innych ustawień. Jeśli zmienię pojedynczy wiersz kodu, różnice powinny pokazywać zmieniony pojedynczy wiersz kodu, a nie setki.

Wszystko inne jest albo nieszkodliwe, albo istnieją lepsze sposoby robienia rzeczy, o których inni mogą być przekonani. Tutaj zasada powinna być następująca: Nie zadzieraj z kodem innych ludzi, chyba że naprawdę go poprawisz. A połączenie stylu A i stylu B jest zawsze gorsze niż oba style A lub B.

Upewnij się, że postępujesz zgodnie z najlepszymi praktykami. Który jest inny w zależności od języka. Ale tam nie potrzebujesz standardów (które mogły być napisane przez kogoś, kto ma dobre intencje, ale w rzeczywistości nie jest tak kompetentny), ale każdy powinien spróbować podać dobre przykłady.

Zdecydowanie unikaj walk o władzę. Nie ma nic gorszego niż jakiś mały Hitler w twoim zespole, który próbuje zmusić wszystkich do swojej woli. I to niestety facet, który zechce napisać twoje standardy kodowania :-(

Wszystkie podane przykłady dotyczą w zasadzie białych znaków i formatowania. Jeśli to jest największy problem, zgadzam się z twoim przełożonym: nie jest to taka wielka sprawa.

Tam, gdzie standardy są naprawdę bardzo przydatne, można nazywać rzeczy i zmniejszać złożoność. Jak nazwać identyfikatory, klasy, gdzie je umieścić itp. Zachowanie spójności nazw jest niezwykle ważne, szczególnie w dużym projekcie. Reguły zmniejszania złożoności obejmują utrzymywanie funkcji pod pewną liczbą linii (dzielenie na mniejsze funkcje) lub utrzymywanie list parametrów poniżej pewnej liczby argumentów (być może powinieneś spakować je do obiektu i przekazać dalej).

Jeśli konkretny programista w twoim zespole pisze kod, który jest trudniejszy do zrozumienia / debugowania, ponieważ zawiera wiele długich fragmentów kodu z nazwami zmiennych o jednolitej literze, jest to dobry powód do przyjęcia pewnych standardów, a nie czegoś, co można naprawić za pomocą skrypt. Dobrze jest wskazać (taktownie) jako rzecz, którą standardy mogą poprawić.

Innym powodem, dla którego menedżer może nie postrzegać tego jako problemu, jest fakt, że tak naprawdę nie odczytujesz często nawzajem kodu. Może się tak zdarzyć, gdy każdy ma swój własny obszar kodu i nie zapuszcza się zbytnio poza nim. Działa to całkiem dobrze, dopóki ktoś nie opuści organizacji, co może się zdarzyć z różnych dobrych lub złych powodów. Standardy, które zwiększają czytelność, ułatwią nowemu deweloperowi przejęcie obsługi fragmentu kodu.

powoduje konflikty podczas scalania, ponieważ ktoś użył swojego IDE do automatycznego formatowania, a on używa innego znaku do wcięcia niż ja

wygląda na to, że to twój problem, a nie formatowanie, ale ponowne formatowanie. Jest to ogromny problem dla SCM, a rada jest prosta: nie rób tego. Więc następnym razem, gdy ktoś ponownie sformatuje wszystkie spacje na tabulatory lub zmieni nawiasy klamrowe na preferowany styl, musisz je uderzyć w dół. Niech zamiast tego dokonają scalenia; stanąć nad nimi, patrząc z dezaprobatą na stratę czasu, którą spowodowała ich bezmyślność.

Alternatywą jest umieszczenie formatera przed zatwierdzeniem, który zawsze formatuje cały kod do standardowego stylu przed zalogowaniem. Jeśli masz zespół programistów, którzy ponownie formatują formatowanie, jest to dobra opcja - SCM zawsze zobaczy ten sam format, więc delty będą małe i przyjemne do scalenia.

Kiedy ktoś sugeruje nowy standard kodowania, w którym pracuję, głosujemy nad nim. Jeśli otrzyma większość głosów, zostaje przyjęty, w przeciwnym razie zostaje odrzucony. Jeśli tego nie zrobisz, nie uzyskasz wpisowych swoich standardów i nie będą one używane, nawet jeśli są udokumentowane.

Jeśli chodzi o konkretny problem, najlepszy zakład prawdopodobnie zacznie się od sugestii Joela i będzie dawał przykład. Zbierz 1 lub 2 programistów, którym zależy na tym, osiągnij porozumienie, a będziesz mieć siłę, by narzucić leniwych.

Teraz, jeśli chodzi o ogólny problem, najlepiej jest po prostu modulować . Każda osoba otrzymuje inny plik, jeśli musisz zachować plik, zachowaj jego standardy kodowania, nawet jeśli jest on inny. Chcesz pisać w tym samym pliku? Utwórz plik podzestawu i dołącz go zamiast tego.

Nie próbuj tego!

Prowadź przez licznik. Postaraj się, aby Twój kod był tak straszny, jak to tylko możliwe, i sprawdzaj wiele okropnie sformatowanych zmian w ładnym kodzie innych ludzi. Kiedy wystąpi (nieunikniona) reakcja, powiedz, że to, co robisz, jest w porządku, ponieważ nie ma standardu kodowania.

Jeśli twoi współpracownicy nie zostaną zlinczowani (!!), możesz skończyć ze standardem kodowania.

Oczywiście jest to strategia wysokiego ryzyka ... :-)