Jak byś sobie radził w takiej sytuacji?

Po miłym pocieszeniu go, co już zrobiłeś, czas stanowczo powiedzieć im, aby sobie z tym poradzili . To nie jest kod jednostki, ale firmy. Jako menadżer potrzebujesz, aby Twój zespół mógł jak najbardziej zadbać o kod i nowe dodatki, które dodasz do zespołu w przyszłości.

”formatowanie kodu to totalnie b *** $ hit "

Jako programista, w firmach, w których brałem udział, egzekwowane są pewne standardy formatowania. Jako główny programista spodziewałbym się, że będą fanami.

„To jak kolory, niektórzy ludzie lubią czerwony, a inny niebieski, to wszystko”

Jako Twój menedżer lubię czerwony, radzę sobie z nim.

„ogranicza moją swobodę”

Formatowanie kodu nie wpływa na swobodę tworzenia eleganckiego rozwiązania. Wzywam B.S. na tym, i Ty też powinieneś.

„sprawia, że ​​kod jest bardziej skomplikowany do odczytania bez wartości dodanej”

Ummmm nie. To sprawia, że ​​zastanawiam się, czy Twój główny programista jest w ogóle liderem ....

Powtarzając - Ty wyznaczyłeś standard, jako menedżer lub zespół, to nie ma znaczenia. Potencjalny klient musi wejść na pokład z nim lub może iść dalej .

Szczerze mówiąc, moja reakcja byłaby następująca:

Bob, doceniam opinie, ale jako zespół zdecydowaliśmy, że używamy czarnego jako naszego obowiązkowego narzędzia do formatowania kodu, i ta decyzja jest ostateczna. Rozumiem, że to nie twoje osobiste preferencje, ale obawiam się, że będziesz musiał nauczyć się z tym pracować.

Ale gdybym chciał zaangażować się w dyskusję?

„formatowanie kodu to kompletna bzdura”

To niezbyt konstruktywna opinia, czy mógłbyś być bardziej szczegółowy?

jak kolory, niektórzy lubią czerwony, a inny niebieski, to wszystko ”

Oczywiście, ale standaryzacja tych„ kolorów ”jest bardzo pomocna i musieliśmy wybrać jeden!

„ogranicza moją wolność”

Podobnie zgadza się z wyrażeniem zgody na pisanie kodu w tym samym języku i wersji tego języka, ale czy możesz sobie wyobrazić chaos, gdybyśmy tego nie zrobili ?

„utrudnia to odczytanie kodu bez wartości dodanej”

To nieprawda. Po chwili czytania kodu w tym formacie nie będzie to w ogóle bardziej skomplikowane - w rzeczywistości będzie to łatwiejsze przeczytać (wartość dodana), ponieważ będziesz musiał się tylko nauczyć jeden styl w całym projekcie. Oznacza to również, że różnice są znacznie bardziej czytelne dla PR, możemy dołączyć innych deweloperów i przyspieszyć ich pracę, a deweloperzy nie będą się przejmować tym, jaki rodzaj formatowania może wyglądać trochę ładniej w danej sytuacji. / p>

Żeby było jasne, jeśli jego opinia była konstruktywna - powiedzmy o formacie „Nie sądzę, aby czarny był nam pomocny z powodów x, y i z, ponieważ większość naszych kod podąża za stylem kodowania bc, z którym Black radzi sobie słabo, czy zamiast tego rozważałeś (inne narzędzie) ”, to jest to bardzo inny scenariusz. Wtedy powinieneś dołożyć wszelkich starań, aby zaangażować się w dyskusję, aby potwierdzić jego obawy i współpracować z nim w rozwiązywaniu ich.

Chciałbym przekonać go o pozytywnych skutkach jednolitego formatowania kodu. Różnice Git stają się znacznie łatwiejsze do zrozumienia, gdy zatwierdzenie n i zatwierdzenie n + 1 mają takie samo formatowanie. Łatwość konserwacji staje się łatwiejsza, zakładając, że formater egzekwuje dobre praktyki. W końcu tworzenie oprogramowania dla firm to sport zespołowy.

Jeśli twój program do formatowania kodu umożliwia definiowanie reguł, zapytaj go, czy są jakieś reguły, których nie lubi, i rozważ omówienie ich ze swoim zespołem.

Jak poradziłbyś sobie z taką sytuacją?

Spróbowałbym zrozumieć oporny punkt widzenia programistów. Mogą mieć dobre strony, które sprawiają, że ignoruję.

Zaimplementowaliśmy automatyczne formatowanie w naszej bazie kodu kilka lat temu i nie powodowało to końca problemów, częściowo ze względu na sposób, w jaki zostało wprowadzone , ale głównie ze względu na sposób, w jaki wpłynęło to na nasz przepływ pracy. Spowodowało to tak dużo dodatkowej pracy przy naprawianiu konfliktów scalania, że ​​w końcu wyłączyliśmy wiele aspektów automatycznego formatowania, więc automatycznie poprawiało tylko rzeczy, które nie powodowały więcej problemów niż rozwiązały. Przeszliśmy również przez wszystkie ustawienia i uwzględniliśmy tylko te, na które wszyscy się zgodzili.

Jednym z problemów z automatycznym formatowaniem jest nie tylko „standaryzacja” złego formatowania, ale także „standaryzacja” dobrego formatowania.

Automatyczny program formatujący nie może odróżnić przypadkowo dodanej podwójnej spacji od podwójnej spacji dodanej, aby element w jednej linii był wyrównany z elementem innej linii. To wizualne skojarzenie może znacznie ułatwić czytanie kodu, ponieważ może być znacznie bardziej oczywiste, że dwie rzeczy w dwóch wierszach są ze sobą powiązane.

Jeśli zamierzasz zaimplementować automatyczne formatowanie, potrzebujesz całego zespołu aby w to wejść.

Musisz zastosować formatowanie globalnie, w gałęzi i scalić w tej gałęzi dopiero, gdy wszyscy będą mieli okazję sprawdzić, jaki to ma wpływ na ich przepływ pracy, zgłosić swoje zastrzeżenia i uzgodnić dalszą drogę.

Większość ludzi kupiłaby automatyczne usuwanie białych znaków z końców linii, niewielu ludzi chciałoby, aby ich ostrożne ręczne dzielenie linii dla czytelności było bezmyślnie ponownie podzielone na niespójny bałagan. -formatowanie narzędzi generuje.

Podejrzewam, że ten programista jest zdenerwowany, ponieważ jest dumny ze swojej pracy, spędził dużo czasu, aby jego kod był jak najbardziej czytelny i łatwy w utrzymaniu, a to automatyczne formatowanie zniszczyło całe ich starannie dopracowane formatowanie.

Mimo, że składnia Pythona już nakłada szereg wymagań na formatowanie, nadal pozostawia dużą swobodę dla indywidualnego programisty.

Krótko mówiąc. Posłuchaj zastrzeżeń swoich programistów, być może uda Ci się ulepszyć bazę kodu dla każdego. Jak mówi PEP 8 - Przewodnik po stylu dla kodu w Pythonie

Głupia konsekwencja to hobgoblin małych umysłów

To jest na początku przewodnika z bardzo dobrego powodu.

Biorąc pod uwagę komentarz jrh, czasami ludzie określają programowanie jako „ bardziej ze sztuki niż z nauki ”, wyśmiewajcie się, ale nie zgadzam się, jeśli chodzi o miękkie aspekty kodowania. Programy nie tylko rozmawiają z kompilatorem / interpretatorem, ale także z programistami, którzy być może będą musieli naprawić, ulepszyć lub utrzymać ten kod w przyszłości.

Aby rozwiązać problem VGR s komentarz, nie sądzę, by to dobre miejsce na krytykę czarnego. Nie korzystałem z tego narzędzia, ale czytając opis, widzę tam głównie dobre rzeczy, zwłaszcza jeśli chodzi o długoterminową konserwację i zróżnicowanie (zmora złożonych połączeń).

To nie pomaga, jeśli Cały zespół nie chce jednak używać tak surowego i bezkompromisowego automatycznego formatowania.

Jeśli mam piekarnię, mogę chcieć, aby moi piekarze używali bochenka o standardowej wielkości. Ułatwia to np. Zakup worków na chleb. Mogę mieć stałą cenę za bochenki, które robię.

Moi piekarze mogą uważać, że ogranicza to ich kreatywność. Niektórzy mogą chcieć zrobić bardzo małe lub bardzo wysokie bochenki chleba.

Inni piekarze mogą uważać, że wolą dużo większy bochenek.

Nie oznacza to, że ich nie ma. t ważne powody do ustanowienia standardu.

Jednak niektórzy piekarze mogą chcieć zwrócić uwagę, że rozmiar bochenka, o który prosiłem, nie pasuje do piekarnika. Byłbym bardzo rozsądnym właścicielem piekarni, gdybym słuchał tych piekarzy.

Członek Twojego zespołu już teraz dostosowuje się do szerokiego zakresu standardów, które mogą ograniczać ich kreatywność i zaprzeczać ich preferencjom. Do tego dochodzi praca w zespole. Nie oznacza to, że nie powinieneś wyznaczać standardów, ale prawdopodobnie rozsądnie jest pozwolić i zachęcić do konstruktywnej, niepowodującej zakłóceń opinii.

„formatowanie kodu to kompletna bzdura”

Nawet jeśli miało to jakiś punkt (a nie ma), czarno-białe stwierdzenia, takie jak ta, często wskazują na bardzo niedojrzałe zrozumienie:

• jak radzić sobie z narzędziami programistycznymi i omawiać ich zalety i wady w zrównoważony i kontekstowy sposób (czyli zawodowo )
• jak radzić sobie w pracy zespołowej

Potrzebujemy profesjonalnych i konstruktywnych opinii, a nie fanatycznych aksjomatów.

"to jest jak kolory, niektórzy ludzie lubią czerwony, inny niebieski, to wszystko" / "ogranicza moją wolność"

Nie, to nie jest jak kolory. Chodzi o czytelność i o wspólne standardy .

Osoby zgłaszające tę skargę podążają ścieżką samolubstwa i nie zdają sobie sprawy z wartości dodanej wspólnych standardów w radzeniu sobie z kodem, a przede wszystkim w zrozumieniu kodu innych ludzi i sprawieniu, by zrozumieli swój.

Fakt, że każdy ma swoje własne preferencje, wręcz przeciwnie, jest dokładnie silny > powód, dla którego powinieneś mieć standardy kodowania, od komentarzy, przez nazewnictwo, po formatowanie.

Poświęcanie swoich „osobistych preferencji” musi być często wykonywane dla lepszej, dobrej pracy zespołowej wszystko polega na kompromis dla najlepszego wyniku.

Wyobraź sobie, że:

• programista A ma swój standard
• programista B używa innych standardów formatowania
• nowy programista „C” musiałby czytać kod w dwóch różnych stylach
• D w trzech… i tak dalej.

To staje się zagmatwane i męczące, ponieważ Twój mózg musi dostosowywać się do różnych stylów i nieustannie przełączać się między nimi . W przypadku jednego wspólnego standardu wystarczy dostosować się raz . We współdzielonych projektach, nawet jeśli open source , egzekwujesz standardy z bardzo ważnych powodów.

A jeśli edytują ten sam plik / klasę? Czy skończy się na różnych stylach kodowania?

„utrudnia to odczytanie kodu bez wartości dodanej”

Myślę, że to, co napisałem powyżej, wystarczy jako odpowiedź na ten kompletny nonsens.

Edycja: proszę spojrzeć także na odpowiedź @ nitarshs, daje to inny interesujący punkt widzenia z punktu widzenia psychologii grupowej, który wydał mi się interesujący.

Być może główna przyczyna problemu nie jest związana z formatowaniem kodu, ale czymś innym ?

Z mojego doświadczenia wynika, że ​​ta sytuacja wyraźnie pokazuje, że odmawiająca osoba nie wyraziła siebie w sposób dojrzały i racjonalny, bez znaczenia, czy ma rację, czy nie.

Nie jestem pewien, jak długo dana osoba była z tobą i zespół, ale naprawdę uważam, że powinieneś lepiej znać skłonność danej osoby, aby wiedzieć, jak radzić sobie w takich sytuacjach.

Zauważyłem, że nawet racjonalni ludzie zachowują się irracjonalnie, gdy nie są z czegoś zadowoleni. Nawet oni mogą nie zdawać sobie sprawy z prawdziwej przyczyny swoich irytacji.

Lub po prostu możliwe, że dana osoba jest z natury niedojrzała, w takim przypadku możesz ją zignorować, o ile tylko ona działają prawidłowo.

Może zabierz je na drinka / kolację i poświęć im trochę uwagi i uwagi. Powinieneś otworzyć się przed nimi i pozwolić im się otworzyć. Spróbuj lepiej poznać swoich kolegów z drużyny i pozwól im lepiej poznać siebie i resztę zespołu.

Tu nie chodzi o formatowanie kodu. Chodzi o bycie dobrym i skutecznym menedżerem oraz egzekwowanie podjętej przez siebie decyzji dotyczącej sposobu pracy zespołu - co, jak powiedziałeś, jest brane pod uwagę i może ogólnie przynieść korzyści zespołowi.

Myślę, że problem najlepiej ilustruje usunięcie szczegółów z Twojego pytania:

Jestem kierownikiem małego zespołu programistów

- - Podjąłem decyzję w sprawie szczegółów tego, jak pracujemy -

Od tego czasu kolega zawsze narzeka i wyraża sprzeciw wobec tej decyzji

To problem ludzi - najtrudniejsza część bycia menedżerem. Kuszące jest, aby spróbować zająć się treścią skarg, ponieważ są to znajome, wygodne terytorium i można się z nimi spierać - w pewien sposób obiektywnie.

Ale oprzyj się tej pokusie, ponieważ to, co naprawdę musisz zrobić, to powiedzieć temu członkowi zespołu, bezpośrednio i jednoznacznie, że musi zaakceptować decyzję i przestać o niej dyskutować.

To osobiste, niewygodne, ale robienie tego jest częścią pracy i tego, czego chce i oczekuje reszta zespołu, zapewniam cię.

W ogóle nie chodzi o formatowanie kodu. Chodzi o najgorszą możliwą formę mikrozarządzania. Za każdym razem, gdy dokonywane jest zatwierdzenie, głupi bezmyślny mikro-menedżer zmienia kod w głupi sposób mikrozarządzania. A ten programista jest wkurzony. (Wygląda na to, że niektórzy tego nie zrozumieli - kiedy mówię „mikro-menedżer”, mówię o narzędziu do formatowania kodu).

Twój zysk i Twoje zespoły na tym wszystkim są nie do odróżnienia od zera. Twoja strata polega na tym, że pokłóciłeś się, zmarnowałeś czas i wkurzyłeś kogoś, kto do tej pory był przyzwoitym programistą. W najlepszym przypadku stracisz jego wsparcie i zaangażowanie. W najgorszym przypadku całkowicie stracisz cennego członka zespołu.

Po prostu wyłącz narzędzie i gotowe. Spowodował i spowoduje więcej szkód, niż jest to warte. Po prostu zdecyduj: czy chcesz pokazać, że masz największe xxxx do pomachania, czy chcesz, aby zespół był szczęśliwy i wykonał pracę?

Kilka miesięcy temu, za sugestią innego współpracownika, wprowadziliśmy obowiązkowe formatowanie kodu w bazie kodu

Od tego czasu kolega zawsze narzeka i wyraża sprzeciw wobec tej decyzji

Podstawowy problem nie wynika z samej decyzji, ale z faktu, że opinia tego współpracownika nie została wzięta pod uwagę przy podejmowaniu decyzji, która ma na niego duży wpływ. Czy zostało to odpowiednio przedyskutowane, z dokładną oceną wszystkich za i przeciw (dotyczy to również automatycznej części egzekwowania), czy po prostu podjęliście decyzję jednostronnie, „ponieważ osobiście mi się to podoba”? Praktyka pokazuje, że osoba z większym prawdopodobieństwem będzie bronić decyzji grupowej, jeśli czuje, że jej opinia została wysłuchana i wzięta pod uwagę, nawet jeśli ostatecznie nie wpłynęła ona na decyzję.

Realistycznie rzecz biorąc, ludzie opuszczają zespoły. Korzystanie z takich stylerów ułatwia innej osobie podjęcie projektu w przyszłości i zrozumienie faktycznej treści, zamiast mówić w czasie, aby zrozumieć jej formatowanie.

Spróbuj pozytywnie zareagować na ich użycie. Na przykład „elementy formatujące kod to bs”, „cóż, łatwiej jest znaleźć proste błędy w kodzie, jeśli wiesz, jak powinien wyglądać” itp. Jeszcze lepiej, jeśli mogą one być bezpośrednio związane z projektem / zespołem.

Gdyby był to więcej niż jeden członek zespołu, zasugerowałbym zorganizowanie spotkania wyjaśniającego, dlaczego to narzędzie formatujące jest używane, jakie przynosi korzyści i dlaczego jest tak ważne, aby Twoi programiści go używali. Ludzie nie lubią zmian, jeśli nie rozumieją ich przyczyn.

Daleko od pełnej odpowiedzi, ale jest jeden punkt, który mnie przytłacza. Formatowanie kodu w twoich zatwierdzeniach w żaden sposób nie musi być tym samym formatowaniem kodu, które jest używane w IDE programisty, gdy pracują na lokalnej kopii repozytorium. Nie wiem, czy kiedykolwiek pracowałem nad wspólnym projektem, w którym każdy programista nie miał sformatowanego kodu tak, jak chciał. Stosowanie formatowania po zatwierdzeniu jest dość łatwe do skonfigurowania za pomocą haków git.

Prowadzisz szczerą rozmowę o tym, co oznacza słowo „profesjonalizm”.

Twój „główny programista” zachowuje się jak nadąsane dziecko. Może posiadać umiejętności techniczne lidera, ale oczywiście brakuje mu umiejętności zawodowych lidera. Chodzi o coś więcej niż tylko pisanie kodu: umiejętności techniczne są koniecznymi , ale nie wystarczającymi warunkiem tego stanowiska. Bycie liderem oznacza, przynajmniej dla mnie, zrozumienie, że nie chodzi o ciebie . To nie oznacza, że ​​nie negocjujesz i nie popierasz siebie, oznacza to , że nie pasujesz do rzeczy, które są najlepszymi praktykami w branży nawet jeśli prywatnie myślisz, że to bzdury (patrzę na ciebie, JIRA).

Zacząłbym od stwierdzenia, że ​​musi to przezwyciężyć dyplomatycznie, a potem przejść do mówiąc to w sposób niedyplomatyczny, a następnie przejdź do PIP. Już zmarnowałeś zbyt dużo swojego cennego czasu na napad złości kogoś innego.

EDYTUJ na podstawie rozmowy w komentarzach

Jeden komentator słusznie wskazuje, że autorytet szefa technicznego może mieć zostały niesprawiedliwie osłabione, powodując niezadowolenie. Chociaż z pewnością zgadzam się, że tak może być, narzekanie na narzędzie w miejscach publicznych jest nieprofesjonalną i niedopuszczalną reakcją na sytuację . Podważaniem należy się zająć bezpośrednio i prywatnie .

Widzę dużą różnicę między naleganiem na dobrze sformatowany kod a narzuceniem automatycznego formatowania na checkin.

W mojej pracy mamy pewnego rodzaju polecenie formatowania kodu, które jest ładowane do IDE , ale kiedy wszystko idzie naprawdę źle, naprawdę możemy coś z tym zrobić, ponieważ nic nie będzie próbowało zastosować go ponownie w czasie dokonywania zmian .

Jestem gotów uwierzyć, że masz prawdziwy problem głównego programisty, który celowo robi rzeczy tak, aby były trudniejsze do odebrania, ale jest całkowicie możliwe, że to, co naprawdę się tutaj dzieje, to autoformatter psuje ręcznie formatowane bloki, w których język został zagięty więc potrzebuje innego formatu pasującego do struktury, którą faktycznie ma, a nie tego, co uważa parser.

Tych przypadków nie można odróżnić od postu. W zależności od tego, co się dzieje, możesz lub nie być w stanie porozmawiać z innymi programistami i dowiedzieć się, co to jest. Uważaj jednak na postawę „Uważam, że jest lepiej, bo tak robi szef”; nie zostanie z tobą rozmowa, ale widziałem już, jak to spada.

Właściwie jest możliwe, że każdy ma z tym problem i wszyscy pozwalają temu facetowi być rzecznikiem. Może uda ci się się tego dowiedzieć.

Ale robiąc swoją należytą staranność, jeśli okaże się, że jest na wycieczce władzy, czas się go pozbyć.

Ostatecznie, jak powiedziały inne odpowiedzi, jako menedżer masz prawo po prostu narzucić styl kodowania, a jeśli komuś się to nie spodoba, może zrezygnować. Jednak prawdopodobnie nie jest to dobre dla morale ani zaangażowania, a pracownik, który niechętnie narzuca swój okrągły kod w stylu kwadratu, prawdopodobnie nie jest szczęśliwy ani produktywny.

W tym celu najlepszy sposób działania prawdopodobnie przekonałoby ich, że posiadanie spójnego stylu w bazie kodu jest korzystne. Niektóre odpowiedzi przedstawiły już pewne punkty, ale są artykuły, a właściwie całe książki, które przemawiają za. Mają rację, że to jak kolory - każdy ma swoje ulubione, ale gdyby każdy programista UI pracujący nad projektem po prostu wybrał swój ulubiony kolor do projektowania, produkt końcowy wcale nie wyglądałby dobrze.

Kilka dobrych artykułów, które właśnie znalazłem dzięki szybkiemu wyszukiwaniu:

• https://www.smashingmagazine.com/2012/10/why-coding-style -matters /

• https://arstechnica.com/information-technology/2013/06/is-it-a-good-idea- narzucić-jednolity-format-kodu-dla-wszystkich-programistów /

Zakładam, że Twoje opinie o komentarzach głównego programisty są dokładne.

To nie są komentarze kompetentnego głównego programisty. Mówię to jako doświadczony programista i menedżer inżynierów oprogramowania.

Informacje zwrotne są niekonstruktywne i bardzo niedokładne. Główny programista, który nie rozumie wartości standardów formatowania, jest głównym programistą, który nie rozumie dynamiki inżynierii zespołowej.

Jest całkiem możliwe, że mają uzasadnione obawy i mógłbym zacząć od tę perspektywę. Jesteś ich menadżerem; pomóż im dobrze wykonywać swoją pracę.

Po pierwsze, prywatnie zadzwoń do nich, przekazując Ci ich kiepskie opinie. Słabo wykonują swoją pracę, jeśli tylko kvetchują.

Następnie pokaż, że jesteś otwarty na praktyczne informacje zwrotne na temat tego, jak ulepszyć implementację standardów kodowania, jeśli Twój programista je posiada. Jeśli potrzebują czasu, aby dowiedzieć się, jak najlepiej to wyrazić, daj im to.

Jeśli nie mają nic konkretnego, powiedz im, żeby wzięli udział w programie i przestali narzekać. To nie tylko bezproduktywne. Jest to szkodliwe dla zespołu.

Powinieneś także zacząć zwracać uwagę na ich ogólne wyniki jako lidera zespołu. Czy faktycznie zapewniają przywództwo pozostałym członkom zespołu, czy po prostu są osobami, które są w pobliżu najdłużej? Takie osoby mogą naprawdę osłabić produktywność zespołu, jeśli działają po prostu jako strażnicy wzrostu (co teraz robi ta osoba).

Z pragmatycznego punktu widzenia uwielbiam formatowanie kodu po prostu dlatego, że znacznie ułatwia ono porównywanie kodu. Ułatwi to również wypychanie, ponieważ jeśli wszyscy używają tego samego programu formatującego kod, to w zasadzie dodanie głupiej, nieistotnej zmiany do pliku nie spowoduje, że git pomyśli, że kod się zmienił.

Osobiście nie jestem szalony, jeśli chodzi o wygląd kodu, ale korzyści opisane powyżej bardziej niż pomagają mi to przeoczyć.

Wiele innych odpowiedzi dotyczy tego, czy formatowanie kodu jest tego warte, czy nie. To jest całkowicie nieistotne dla tego pytania.

Tu chodzi o komunikację, a nie o przekonanie go, że standardowe formatowanie kodu jest świetne. Zrób krok do tyłu. Musisz przekazać:

• Co próbujesz osiągnąć. *
• Jak planujesz mierzyć sukces.

Ta dodatkowa informacja pozwoli im spojrzeć na sprawy z Twojego punktu widzenia, co często wystarcza, aby ich uspokoić. Druga część (mierzenie sukcesu) jest konieczna, aby wykazać, że rzeczywiście włożyłeś w to przemyślenie i ułatwiasz im zaufanie. Pozwala im również znaleźć alternatywy lub modyfikacje zasad, które spełniają zarówno Twoje żądania, jak i ich żądania.

Jeśli to się nie powiedzie, istnieją 2 główne sposoby radzenia sobie z pracownikami, którzy nie zgadzają się ze zmianą polityki: p>

• Posłuchaj ich. Są opłacanymi profesjonalistami i ich obawy mogą być ważniejsze niż myślisz.
• Zamknij ich. „To jest decyzja. Wiem, że ci się to nie podoba i słyszałem Twoje obawy, ale teraz chcę, abyś to zaakceptował i pracował z zespołem”.

* Nie chodzi o listę korzyści, chodzi o Twoją motywację do wprowadzenia zmiany. Może chcesz wzmocnić zespół i dlatego zdecydowałeś, że zespół zdecyduje o standardach kodu i formatowaniu. Może właśnie wdrożyłeś sugestię z góry. Może planujesz wiele zmian w zakresie automatyzacji i / lub analizy, które przyniosą korzyści ze standardowego formatowania. Może chcesz użyć standardowego formatowania, aby lepiej sprzedać swój zespół przełożonym. Może wypchnąłeś standardowe formatowanie tylko dlatego, że je lubisz.

formatowanie kodu to kompletna bzdura

Można to łatwo obalić, biorąc przykładowy kod (nieznany deweloperowi), usuwając wszystkie znaki nowej linii, tabulatory i redukując wiele pojedyncze spacje i poproszenie pracownika, aby powiedział, co robi kod.

To jest jak kolory, niektórzy ludzie lubią czerwony, a inny niebieski to wszystko.

Tak. Tak jest w przypadku prawie każdego sporu dotyczącego programowania. Tabulatory a spacje, nawiasy w stylu C lub egipskie nawiasy… Ale odpowiedź jest zawsze taka sama: niektórzy lubią jeździć po lewej stronie, inni lubią jeździć po prawej stronie. Jedno i drugie jest w porządku, ale pozwolenie na oba jednocześnie prowadzi do szaleństwa.

Lub, jeśli naprawdę chcesz użyć jego analogii przeciwko niemu: ale użycie niebieskiego i czerwonego razem daje fiolet, co oznacza, że ​​ nikt nie dostaje tego, czego chce.

Podjęto decyzję wykonawczą o wyborze tego formatu. Twój pracownik nie ma uprawnień do unieważnienia tej dyskusji. Koniec opowieści. Nie poddawałbym się dalej tej linii pytań.
Zawsze jestem otwarty na konstruktywną informację zwrotną, ale argument twojego pracownika jest argumentem twardości, nie jest konstruktywny. Nie pozwól im zmienić tego w rywalizację o bycie najbardziej upartym. Nawet jeśli wygrasz, sygnalizujesz swoim pracownikom, że upór jest dopuszczalnym sposobem wyrażania sprzeciwu.

Nie oznacza to, że nie możesz mu pomóc, jeśli jest to po prostu kwestia braku doświadczenia. Może znajdziesz zautomatyzowany program formatujący, który będzie mógł wpisać swój własny format i przekonwertować go.

Powiedziałem ludziom, którym się udało, że nie obchodzi mnie czytelność ich kodu, zanim go sprawdzą. Nie oczekuję, że w każdej sekundzie będą w pełni przestrzegać wskazówek dotyczących stylu. Dopóki kod zostanie wyczyszczony przed włączeniem do gałęzi, jest to dopuszczalne. Często zaczynam od szybkiego i brudnego kodu i oczyszczam go dopiero, gdy zacznę działać. Niektórzy ludzie pracują w ten sposób i to jest w porządku, o ile na końcu nie pomijają wymaganego czyszczenia.

zmniejsza to moją wolność

Nikt nie może robić, co chce. Konieczność płacenia pracownikom również ogranicza swobodę firmy.

Wysiłek potrzebny do sformatowania kodu od samego początku zwróci dywidendy, gdy ktoś inny będzie musiał przeczytać jego kod.

Biorąc pod uwagę uwagi tego pracownika, podejrzewam, że prawdopodobnie narzekał na formatowanie kodu lub konwencje nazewnictwa innych ludzi. Zwróć uwagę, że inni poczują to samo, jeśli chodzi o jego formatowanie i nazywanie. Jednolitość oznacza, że ​​każdy może czytać kod każdego, niezależnie od tego, czy jest to osobiste preferencje każdego.

sprawia, że ​​czytanie kodu jest bardziej skomplikowane bez wartości dodanej

To trudniej mu teraz czytać, ponieważ nie jest do tego przyzwyczajony. Im bardziej opiera się zmianie, tym dłużej będzie z nią walczył. Decyzja została podjęta, to się dzieje, koniec historii.

Skoncentruję się na tym, że pracownik został poinformowany o nowym formacie i oczekuje się, że będzie go teraz przestrzegać. Jeśli nie zastosują się (lub nie włożą prawdziwego wysiłku), wszelkie opóźnienia spowodowane odrzuceniem ich żądań ściągnięcia spadają na ich barki.

Żądania scalenia kodu muszą być sformatowane za pomocą tego narzędzia, w przeciwnym razie nie można ich dodać do oprogramowania.

Mówiąc „nie można”, masz na myśli, że jest to niedozwolone lub niemożliwe (np. recenzent zawsze odrzucaj prośbę)?

Jeśli to drugie, tego potrzebujesz. Jeśli programista nie przestrzega reguł formatowania, jego żądania nie są akceptowane, a wszelkie opóźnienia wynikające z tego są jego odpowiedzialnością, co skutkuje złą oceną wydajności.

Jeśli to pierwsze, to Ty ' naprawdę polegać na tym, że każdy świadomie będzie uczestniczył w systemie, który działa tylko wtedy, gdy wszyscy to robią. Obecnie masz do czynienia z kimś, kto się trzyma. Możliwe, że się powstrzymuje, ponieważ wie, że nie egzekwujesz tego, a tylko prosisz.

Jesteś menadżerem, więc spróbujmy zarządzać nim (i tym), a nie tylko go oszukiwać lub postrzegać jako problem:

„John , moim obowiązkiem jest uczynić to tak prostym, jak to tylko możliwe, dla wszystkich i dla przyszłych pracowników, a nie tylko dla niektórych dzisiejszych pracowników. ”

„ Gdy większość programistów przegląda kod, jest to szybsze, jeśli mogą pewne rzeczy za pewnik, takie jak sposób wykonania kodu i sposób ujednolicenia niektórych rzeczy. Jeśli kiedykolwiek będzie potrzeba, aby ktoś przeanalizował kod [Zewnętrzny audyt kodu? Odpowiedzialność? Należyta staranność?] silny>, lepiej, jeśli jest ustandaryzowany. Masz rację, że niektórzy tacy jak niebieski, a inni tacy jak czerwony, a poza pracą, oboje możemy kodować w dowolny sposób. Ale pisząc kod, który zespół ma do utrzymania, a przyszli inżynierowie muszą szybko i dokładnie to zrozumieć, wierzę, że standaryzacja pomoże, a ja przewodzę zespołowi - nie ty, nie Bob, nie Alice, więc muszę wykonywać tego rodzaju telefony, jeśli czuję potrzeba - a ja tak. ”

„ Kiedy w przyszłości zaczniesz zarządzać takimi projektami, możesz wykonać telefon, który Ci się podoba i oczekiwać, że inni podążą za Twoimi wskazówkami. Ale mam nadzieję, że kiedy to zrobisz - i jesteś dobry, więc prawdopodobnie [komplement nigdy nie zaszkodzi, jeśli to prawda, jeśli nie pominiesz] - że ponownie się rozważysz i zobaczysz korzyści, jakie daje, nawet jeśli narzuca dyscyplinę, w której nie widzisz żadnego sensu, w tej chwili. ”

„ Wierzę, że zaoszczędzi to niewielką ilość czasu w codziennej pracy, kiedy kod jest ponownie tworzony. zmniejszy liczbę błędów i uważam, że jest to profesjonalne. Chciałbym, żebyś to uszanował, nawet jeśli się z tym nie zgadzasz ”.

Białe znaki są w rzeczywistości częścią składni python . Czytelność jest już zaprojektowana w języku. W rzeczywistości python ma własne zalecenia dotyczące formatowania kodu. Sprawdzone metody, konwencje nazewnictwa itp. Nazywa się to PEP (dokładniej PEP8). Zacznij tam! Znajomość PEP to coś, co mogą dodać do swojego CV!

Jak poradzisz sobie w takiej sytuacji?

Myślę, że czterech innych programistów jest po prawej po stronie tego argumentu i możesz się tutaj mylić. Szczerze przyjmij opinie swoich pracowników i weź je sobie do serca. Postaw się na ich miejscu. Jeśli wypłata opiera się na wynikach, a to narzędzie je zmniejsza, zasadniczo bierzesz od nich pieniądze .

Myślę, że następnym dobrym krokiem jest podjęcie decyzji, czy nadal używać tego narzędzia. Jeśli uważasz, że jest to korzystne, wyjaśnij dlaczego . Na przykład, jeśli użytkownik końcowy / klient daje lepsze recenzje lub przyszłe projekty, ponieważ kod jest piękny - powiedz to swoim pracownikom! To oznacza więcej pieniędzy w kieszeni!

Pamiętaj, że Twoje wskaźniki KPI dotyczące zapewniania jakości mogą nie odpowiadać opisowi stanowiska członków Twojego zespołu. Spraw, aby Twój zespół miał poparcie dla swoich projektów. Zrób to coś, z czego są dumni. Kiedy silne poczucie własności jest normą w miejscu pracy - gwarancja jakości jest czymś naturalnym.

Warto rozważyć dwie dodatkowe kwestie.

1. Pytasz o czarno-białą odpowiedź na problem w skali szarości. Twoje zasady formatowania kodu mogą być rozsądne, mogą być złagodzone, Nitpicking. Widziałem różne zasady. Przede wszystkim więc sprawdź, czy wymagane reguły formatu kodu są rozsądne, czy nie.
2. Czy formatowanie kodu i wszystkie standardowe reguły kodu zostały właśnie narzucone z góry, czy też zostały uzgodnione przez programistów z zespołu - tych, którzy faktycznie piszą kod i czytają / używają go od innych? Dobrą praktyką może być ustalenie zestawu standardowych reguł kodowania przez komisję - tylko raz, a następnie te zasady są egzekwowane. Jeśli większość deweloperów się na to zgodzi, to masz duże szanse, że te zasady będą rozsądne, a jeśli ktoś narzeknie, to jest to problem. Jeśli reguły zostały po prostu narzucone dekretem jednej osoby ... możesz mieć tam problem.
3. Alternatywą jest znalezienie narzędzia do inspekcji / formatowania kodu, które jest mniej więcej standardem branżowym dla używanego języka. Na przykład dla C # używam Resharper. Wtedy decyzja będzie bezstronna, a formatowanie może być wykonane mniej więcej automatycznie w edytorze, w trakcie pisania kodu. Jeśli Resharper jest szczęśliwy, jestem szczęśliwy. Znajdź coś takiego dla Pythona.

Moja osobista zasada, kiedy przewodzę zespołowi, to naleganie na ścisłe zasady tylko wtedy, gdy wygląda czyjś kod naprawdę brzydkie ... a gdyby tak się stało, moglibyśmy spojrzeć na głębszy problem niż tylko formatowanie kodu. Problem, który zaczyna się od HR i zatrudniania niewłaściwej osoby, w przeciwnym razie, jeśli kod wygląda mniej lub bardziej przejrzyście i uporządkowany, a jego architektura / projekt jest dobry, szukanie dziury w formatowaniu często sprawia więcej kłopotów niż jest to warte.

Spójność to słaby argument. Dla osoby, która nie zgadza się z określoną regułą formatowania, może się wydawać, że jest problem z mikrozarządzaniem lub żądnym władzy architektem. Formatowanie prawie nigdy nie ma znaczenia - „jest jak kolory, niektórzy lubią czerwony, a inny niebieski”.

Prawdziwą zaletą reguł automatycznego formatowania jest to, że programiści nie tracą czasu na omawianie rzeczy, które nie mają znaczenia. Zbyt dużo czasu poświęca się na przeglądanie kodu w komentarzach o wcięciach. Znacznie więcej mocy mózgowej powinno być skoncentrowane na rzeczywistych problemach z kodem.

Przedstaw deweloperowi termin Bikeshedding . Wyraźnie zaznacz, że uważasz jego komentarze za wielki wkład w projekt szopy rowerowej. Marnuje czas innym. Jest złym graczem zespołowym. Zostanie użyty przeciwko niemu podczas oceny.

Oprócz innych odpowiedzi, które już całkiem nieźle omawiały temat The Talk - metodologia wprowadzania formatowania do procesu, czy Bobowi się to podoba, czy nie:

Przeprowadź przegląd kodu za pomocą zasada czterech oczu w każdym żądaniu scalenia. Twój master powinien być modyfikowany tylko za pomocą zaakceptowanej prośby o scalenie, w żaden inny sposób. Wszystkie prośby o scalenie muszą zostać poddane kontroli jakości, tj. inny członek zespołu musi przejrzeć kod. Wymuś formatowanie i pozwól odrzucać MR Boba z powodu nieprawidłowego formatowania kodu.

Jeśli Bob odmówi spełnienia, jego prośby o scalenie utkną w zawieszeniu. Na pytanie „dlaczego funkcja XY nie została wykonana, mimo że termin już dawno minął?”, Bob może odpowiedzieć: „Robiono to już od jakiegoś czasu, ale został odrzucony przez kolegę Y”. Możesz argumentować, że to się nie robi. Do tego służy kontrola jakości. Współpracownicy muszą odrzucić takie prośby i zmienić przypisanie Boba, wtedy jego zadaniem jest sobie z tym poradzić.

Zachowanie w ten sposób ma różne stopnie agresji, więc jeśli chcesz, aby ton był jak najbardziej przyjazny, uważaj, jak to wdrażasz. Niemniej jednak - i tak powinieneś dokonać przeglądu kodu.

Prywatnie - rzekome stwierdzenia Boba dotyczące przydatności formatowania skłaniają mnie do myślenia, że ​​prawdopodobnie nie nadają się do roli głównej lub po prostu brakuje im określonego wykształcenia w niektórych obszarach . Być może znają kod źródłowy, ale z powodu braku najlepszych praktyk pomogli przekształcić go w gigantyczny bałagan i tylko oni znają ścieżkę przez chaos. Takie rzeczy są niebezpieczne, ponieważ możesz stać się bardzo zależny od jednej osoby, ponieważ Twój kod źródłowy staje się coraz trudniejszy do utrzymania.

Myślę, że w tym przypadku możliwe byłoby dodanie haka git, który zmienia format kodu na pożądany przez zespół przy zatwierdzaniu, i inny (używany tylko przez nich), który zmienia format kodu na format jeden pożądany przez członka zespołu podczas aktualizacji.

Jeśli członek zespołu tak bardzo to odczuwa, może to być również dobra okazja, aby dowiedzieć się więcej o programie formatującym kod i narzędziach git, a także o całej wiedzy, która może się przydać później.

Istnieje wiele odpowiedzi, które koncentrują się na dobrych argumentach technicznych. Podsumowując: zespół podjął rozsądną decyzję, jak postępować, a jedna osoba odrzuca decyzję zespołu i wskazówki kierownika.

Rozmowa, którą chciałbym mieć, jest bardziej podobna do: czy właśnie zadzwoniłeś moje instrukcje i decyzja zespołu "bzdury"? Czy naprawdę narzekałeś, że otrzymywanie wynagrodzenia za pracę „ogranicza Twoją wolność”? Zdecydowanie sugeruję, abyś teraz sprawdził ładnie sformatowany kod, a ja umówię się na spotkanie z działem HR w celu omówienia szacunku dla Twojego pracodawcy, menedżera i zespołu.