Więc twój starszy i ty nie zgadzacie się co do tego, co oznaczają konwencje kodowania i który sposób jest bardziej czytelny. Sposobem na rozwiązanie tego problemu jest wyjaśnienie zrozumienia, aby wszyscy byli na tej samej stronie.

Dlatego zareagowałbym w następujący sposób:

S: Dlaczego robiąc to? Zmieniasz mój kod. Jesteśmy zespołem ...

J: Starałem się, aby było zgodne z konwencją kodowania. Mówi, że powinniśmy zrobić XXX i ulepszyć istniejący kod, gdy go zobaczymy?

A potem posłuchaj, co mówi i naprawdę spróbuj zrozumieć jego punkt widzenia.

Po zakończeniu debaty technicznej (i miejmy nadzieję, że nastroje opadły), odniosę się do społecznej strony jego opinii. Ponownie, najlepiej działa jako pytanie:

Co mam zrobić, jeśli w kodzie znajduje się coś, czego nie rozumiem lub myślę, że można to zrobić prościej?

I jeszcze raz słuchaj, czego chce.

Dzięki temu osiąga się kilka rzeczy:

1. Jego raczej emocjonalna reakcja wskazuje, że jest emocjonalnie zaangażowany w swój kod i czuje swoją ekspercką ocenę lekceważony. Prosząc o jego wiedzę, pokazujesz, że cenisz jego wiedzę, która powinna uspokoić dyskusję.
2. Komunikuje, że nie chciałeś go lekceważyć lub afiszować się z normami społecznymi. Raczej uświadamia mu to, że po prostu jeszcze nie wiedziałeś, czego się od ciebie oczekuje, i że próbujesz to naprawić.
3. Wyjaśnia, czego się od ciebie oczekuje, aby uniknąć dalszych przypadkowych konfliktów.

Odpuść. Próbujesz pójść na kompromis między 3 lub 4 priorytetami: swoimi preferencjami, konwencjami kodowania, preferencjami starszego programisty, którego kod został zmieniony, oraz umiejętnością zespołu do zrozumienia kodu. Według starszego programisty jego styl kodowania ma sens dla zespołu. Zatem priorytety 3 i 4 można łączyć. Teraz jest między wami, konwencjami kodowania i starszym zespołem programistów +.

Pomiędzy tymi opcjami, konwencje zespołu i twoja relacja ze starszym programistą, moim zdaniem, mają większe znaczenie dla zdolności zespołu do wykonania pracy niż twoje preferencje i konwencje kodu.

Biorąc pod uwagę to, że jesteś nowy, radziłbym odpuścić i nauczyć się z tego, że to, co uważasz za słuszne, nie jest konieczne, co zawsze powinno się wydarzyć.

Podejrzewam, że inni tutaj mogą się cofnąć i zdecydowanie jest miejsce na inną kolejność priorytetów, ale prawdopodobnie jest to droga, którą wybrałbym, przynajmniej będąc stosunkowo nowym pracownikiem. Powodzenia!

Już cofnąłeś zmiany. Więc odpuść.

Biorąc to pod uwagę, następnym razem tak się stanie. Upewnij się, że nie ma miejsca na wahania przy interpretacji konwencji kodowania. Ponieważ, jeśli masz zamiar stoczyć z kimś bitwę, wybierz bitwę, w której masz 100% szans na wygranie.

Jest to ważne zwłaszcza jeśli nie masz tak dużego kapitału społecznego zarządzanie jak ta osoba.

Pamiętaj też, aby dodać testy jednostkowe, zanim zmodyfikujesz zbyt dużą część jego kodu. Jeśli wprowadzisz błędy do jego kodu, nigdy nie usłyszysz końca. A kiedy znajdziesz coś z jego strony, warto to zmienić. Następnie idź dalej, ale bądź ostrożny i przestrzegaj oficjalnych konwencji (a jeśli nie, oficjalne konwencje nie dotyczą konkretnego problemu, postępuj przynajmniej zgodnie z konwencjami Code Complete).

Jeśli narzeka do Ciebie, możesz po prostu powiedzieć mu, żeby walczył o zmianę konwencji kodowania, a kiedy uzyska zgodę na te nowe konwencje kodowania, które ma na myśli, z przyjemnością się im przyjrzysz i wdrożyć je, ale nie wcześniej.

Ponadto prawdopodobnie powinieneś poprosić kierownictwo o zorganizowanie cotygodniowych przeglądów kodu. W końcu, jeśli masz okazję omówić decyzje dotyczące kodowania podczas przeglądu kodu. Zapewni ci to bezpieczniejszy i mniej konfrontacyjny sposób zrozumienia i / lub zakwestionowania niektórych złych nawyków rówieśników.

Wiele się dzieje

Dzieje się tu sporo rzeczy. Wiele z nich zostało już omówionych i krótko o nich wspomnę oraz o mojej wizji tego, co należy, a czego nie należy z nimi robić. Jest jednak jeden punkt, którego jeszcze nie widziałem, a który uważam za największy problem i omówię go bardziej szczegółowo.

Błędy Poprawki w stylu &

Naprawiłeś problem przy jednoczesnej zmianie kodu.

Moim zdaniem nie jest to duży problem, ale ogólnie lepiej jest trzymać osobne rzeczy w osobnych zatwierdzeniach. To wymagałoby dodania oddzielenia konfliktu od poprawki błędu również tutaj.

Różne poglądy

Nie zgadzasz się co do tego, która wersja jest lepiej zgodna z konwencjami, jest bardziej czytelna i bardziej do utrzymania.

Jeśli jest twoim seniorem, dobrze byłoby pójść za jego przykładem. Ewentualnie dobrze byłoby, gdyby ktoś z firmy spojrzał na kod razem z wami i spojrzał na niego z tych trzech perspektyw.

Trudny kod

kod był trudny do zrozumienia.

Uważam, że przydatne jest zadawanie pytań dotyczących kodu w takich sytuacjach, zwłaszcza jeśli wiesz, kto napisał kod (i / lub kod został napisany niedawno). Zadawanie pytań może zarówno doprowadzić cię do lepszego zrozumienia kodu, jak i pomóc drugiej osobie zrozumieć, dlaczego kod był trudny do zrozumienia na początku. Często prowadzi to do tego, jak sam kod może stać się jaśniejszy, co możesz następnie omówić przed jego wdrożeniem.

Atak

Druga osoba staje się dość agresywna, sugerując, że ty muszą się rozstać i udają się do twojego przełożonego, aby powstrzymać cię przed pewnym kodem.

Jak napisano, jest to dość poważne. Zależy to trochę od tego, w jaki sposób zachodzi różnica między faktycznymi rzeczami, które powiedział, a sposobem, w jaki go tu sparafrazowałeś, ale sam sposób, w jaki to napisałeś, powinien być powodem do rozmowy z przełożonym. Jeśli tak, nie mów o kodzie, ale o jego stosunku do ciebie, w którym wydaje się, że rozważa grożenie ci w porządku.

Jego kod

Nie chce, żebyś edytował jego kod.

Moim zdaniem to jest największy problem. Jest to dość toksyczne podejście i myślę, że uderza w sedno problemu. Programiści-hobbyści często bardzo chronią swój kod, a czasami można to zobaczyć w przypadku profesjonalnych programistów, którzy sami pracowali nad kodem. Jednak nie ma miejsca w żadnym profesjonalnym otoczeniu i jest wyjątkowo toksyczny, gdy jesteś odpowiedzialny za kod jako zespół.

Ostatecznie problem polega na tym, że kod nie jest jego. Kod należy do firmy lub zespołu, ale nie do niego. Zamiast tego jest to kod, który napisał. Myślę, że ważne jest, aby nie nazywać tego jego kodem, ale kodem, który napisał. Bez stwierdzenia, że ​​to nie jest jego kod lub poprawiania go, gdy mówi, że to jego kod, warto konsekwentnie nazywać go kodem, który sam napisał. Dotyczy to zarówno momentu, w którym omawiasz z nim sytuację, jak i podczas omawiania sytuacji z innymi członkami zespołu lub menedżerem.

Przede wszystkim powiedziałbym, że pozwoliłbym na ten incydent bądź tym, czym na razie jest. Jednak nie wychodziłbym też z drogi, aby uniknąć dotykania kodu, który napisał w przyszłości. Wygląda na to, że to znowu się pojawi, a chodzenie po skorupkach jajek przez cały dzień nikomu nie pomoże.

Zakładając, że jesteś w zespole składającym się z większej liczby członków niż wy dwoje, pierwszą rzeczą, jaką możesz zrobić, jest porozmawianie o problemie z innymi członkami zespołu. Zapytaj ich, czy doświadczyli tego samego zachowania i jak sobie z tym poradzili lub jak sobie z tym poradzili. Twoi współpracownicy to zasób, którego nie należy lekceważyć. Jeśli w Twoim zespole nie ma innych członków, możesz zamiast tego zapytać innych kolegów, którzy w przeszłości musieli z tą osobą współpracować.

W takim przypadku, jeśli ten programista okaże się nadopiekuńczy wobec napisanego przez siebie kodu przy innej okazji postaraj się zastosować sugestie kolegów. Poza tym możesz go również zapytać, czy jest zdenerwowany, ponieważ zmieniłeś kod, który napisał, lub że jego zdaniem zmiana wpływa negatywnie na kod. Są to dwie zupełnie odrębne kwestie i ważne jest, aby uświadomić mu, że tak jest.

Po tym momencie wydaje się, że nadszedł czas, aby eskalować problem. Porozmawiaj z kierownikiem zespołu lub menedżerem (w zależności od tego, który jest bardziej odpowiedni) i wyjaśnij im, że ta osoba wydaje się mieć problem z dotknięciem napisanego przez siebie kodu. Chociaż jesteś otwarty na dyskusję na temat jakości dowolnego kodu (którym powinieneś być), wydaje się, że wydaje się, że to fakt, że ta osoba chce, aby kod, który napisał, nie był dotykany (przez Ciebie - jeśli takie jest Twoje wrażenie jest). Wyjaśnij, jak to fałszywie dzieli własność, odpowiedzialność i zrozumienie kodu oraz jak to jest szkodliwe dla produktu i zwiększa sposób, w jaki firma polega na określonych ludziach. (Oczywiście takie wyjaśnienie nie powinno być prawie tak szczegółowe podczas rozmowy z kierownikiem zespołu, jak w przypadku rozmowy z menedżerem).

Podsumowując

Zasadniczo, Myślę, że najważniejsze jest wyodrębnienie poszczególnych problemów i indywidualne podejście do nich. Powinno to również znacznie ułatwić radzenie sobie z każdym z nich, ponieważ teraz wiesz, co się dzieje.

Widziałem kilka odpowiedzi „Odpuść sobie”. Nie mogę się z tym zgodzić, ponieważ problem będzie się powtarzał.

Zespół potrzebuje standardów, szczególnie po to, aby uniknąć takich kłótni. Powiedziałbym, żebym ponownie porozmawiał ze swoim współpracownikiem, kiedy temperament nieco opadnie. Poproś go, aby przejrzał z tobą standardy kodowania i wspólnie ustalili - jeśli to możliwe - jak Twoim zdaniem powinien być zorganizowany kod. Jeśli wszyscy dojdziecie do porozumienia, coolio. Jeśli nie, bez urazy rozpoznaj, że po prostu nie jesteś na tej samej stronie, i poproś menedżera o pomoc w rozwiązaniu problemu.

Usunąłeś swój konkretny przykład (który uważałem za zły, oferuje jakiś kontekst), ale pozwólcie, że dodam tylko jedną rzecz ... Ta potencjalnie trudna część (zwiększanie liczby modulo indeksu w celu zawinięcia do 0) powinna być zrozumiała dla J Random Programmer, ale nie zaszkodzi wpaść w szybki numerek komentarz na początku wiersza jako przypomnienie ...; D

Nie sądzę, żebyś odpuścił: Twój kolega bardzo chroni napisany przez siebie kod. Więc za każdym razem, gdy zmienisz fragment kodu, który napisał i nie zawiera on błędu, jest bardzo prawdopodobne, że przyjdzie z Tobą „porozmawiać” o tym.

A Twój kolega próbuje Cię zastraszyć, nie pomyl się.

Po pierwsze , kod, nad którym oboje pracujesz, nie jest jego ani twój. Jest własnością tego, kto ci płaci.

Po drugie , nie powinieneś robić tego, co mówi, że powinieneś robić, chyba że jest twoim szefem, a on nie. Powinieneś robić to, czego żąda od ciebie pracodawca.

Po trzecie , zgadzam się z tobą, że powinieneś zostawić rzeczy lepsze od tego, co znalazłeś, więc uczynienie kodu bardziej czytelnym jest dobra rzecz.

Nie chcesz więc komplikować sobie życia trzema liniami kodu. Dobrze na tobie! Ale co zamierzasz zrobić następnym razem?

Sugeruję, aby następnym razem zaangażować kierownika / menedżera zespołu. Zobacz punkty, jeden, dwa i trzy.

Chociaż Twój „starszy” rówieśnik mógł przesadzić, powinieneś również wziąć pod uwagę możliwość, że miał on w pewnym sensie rację.

Niestety, zmiany usunęły sam kod: być może jest to zazwyczaj lepsze użytkownicy spoza IT, ale w tym przypadku utracono ważną informację.

Sposób, w jaki to widzę, poprawił czytelność kodu według większości formalnych metryk: warunki są bardziej logicznie zorganizowane, są szelki i takie tam. Jednak wprowadzenie przez ciebie operatora % (reszta liczby całkowitej) jest sprytną sztuczką, która zmyli 90% młodszych programistów i najwyraźniej również seniorów. Teraz zbyt rozwlekły kod jest zły, zbędne testy są złe, ale sprytne sztuczki są po prostu okropne, chyba że masz pewność, że wszyscy programiści są co najmniej tak sprytni jak ty. I masz już dowód, że tak nie jest.

Ponadto, chociaż dokumenty Twojej firmy mówią, że powinieneś „poprawiać kod, który nie jest napisany w tym stylu”, prawdopodobnie lepiej byłoby wspomnieć takie zmiany pierwotnego autora, jeśli jest dostępny. Szybka wiadomość w stylu „Słuchaj, miałem problemy z debugowaniem tego kodu, nie sądzisz, że w ten sposób jest bardziej czytelny?” mogło zaoszczędzić wam obu kłopotów.

Kiedy jesteś nowy, zwykle dobrze jest poświęcić trochę czasu na obserwację dynamiki i wyczucie zespołu itp., zanim podejmiesz się wprowadzenia jakichkolwiek dużych zmian. Dobra praktyczna zasada brzmi: „Jeśli coś nie jest zepsute, nie naprawiaj tego” lub następstwem tego: „Gdyby było zepsute, ktoś by to teraz naprawił”. Jeśli kod, o którym mowa, był dużym problemem, prawdopodobnie zostałby (a przynajmniej powinien zostać już naprawiony). Możliwe, że część kodu, który napotkasz w tym zadaniu, będzie wymagała naprawy, ale poczekaj, aż jesteś lepiej zaznajomiony z systemem grupy, zanim zdecydujesz, czy jakikolwiek taki kod się kwalifikuje.

Pomimo tego, ile wysiłku włożono w opracowanie uniwersalnych standardów kodowania / dokumentacji, KAŻDE MIEJSCE PRACY BĘDZIE POSIADAŁ WŁASNE STANDARDY i potrzeba czasu, aby wywnioskować, co to dokładnie jest.

Możesz pozwolić temu incydentowi minąć, ale nie powinieneś czuć się źle. Musisz tylko wybrać swoje bitwy.

Twoja mentalność jest absolutnie poprawna. Ilekroć wracamy do starego kodu, jeśli nie jest on łatwy w utrzymaniu, musimy najpierw go zrozumieć. Kiedy to zrozumienie zostanie osiągnięte, jeśli nie udokumentujemy lub nie ułatwimy drogi do tego zrozumienia, marnujemy czas dalszych opiekunów w przyszłości, podobnie jak oryginalny programista obniżył ten koszt. Dlatego obowiązkiem każdego programisty wartego swojej soli jest dokumentowanie lub ulepszanie kodu na bieżąco (to drugie jest mniej ryzykowne, gdy masz solidny i wyczerpujący zestaw testów, który zapewnia, że ​​refaktory i ulepszenia nie psują funkcjonalności). Pozostawianie komentarzy nie jest idealne, ale pozostawia zapach, że kod potrzebuje trochę miłości w przyszłości.

Twój zespół również stosuje właściwe podejście do konwencji kodowania. Konwencje to nie zasady, więc musi istnieć możliwość ich łamania, gdy ma to sens. Ale reprezentują ideał, który nie zawsze był osiągany, i bardziej praktyczne jest egzekwowanie konwencji kodowych w nowym i zaktualizowanym kodzie, niż wyczerpująca refaktoryzacja. W idealnym projekcie kod nigdy nie powinien wyglądać tak, jakby ktoś go napisał. Dzięki temu wszyscy programiści mogą sprawdzić swoje ego przy drzwiach i traktować kod jako kod zespołu, martwić się o jakość kodu, a nie o to, kto co napisał.

To prowadzi nas do Twojego współpracownika. Ich zachowanie nie jest niczym niezwykłym, jak mogłoby się wydawać, ponieważ programiści mają tendencję do odczuwania dumy i własności nad swoim kodem (lub czasami starają się obwiniać innych tylko po to, aby zobaczyć siebie w historii) i mogą rozwinąć ego pomimo wysiłków, aby temu przeciwdziałać . Inni w ogóle się nie opierają. „Mój kod” to złe podejście, cały kod powinien należeć do zespołu. Istnieje niespójność między jego twierdzeniem, że zakodował rzeczy tak, aby były zrozumiałe dla zespołu, jeśli jest to sprzeczne z wytycznymi zespołu dotyczącymi kodowania. Daje do zrozumienia, że ​​jest to zakodowane tak, aby było zrozumiałe najpierw dla niego, a nie dla zespołu, i jest zdenerwowany, że zrujnowałeś jego rozumienie, mając odwagę zmieniać rzeczy (cały dobry kod powinien być napisany tak, aby był łatwy do utrzymania i usunięcia nie bądź nieśmiertelny).

Pogarsza się, gdy twierdzi, że nigdy nie możesz zrozumieć jego kodu i grozi, że wykorzystasz jego wpływ, aby wyrzucić Cię z pracy. Samo to jest ogromnie nieprofesjonalne, ale w odpowiedzi na niewielkie formatowanie jest ogromnie nieproporcjonalne.

Musisz wybierać swoje bitwy, a ja odpuściłem stronę formatowania. Jeśli jesteś nowy w zespole i ktoś mówi, że nie przestrzegasz konwencji kodowania, wszystko, co naprawdę możesz zrobić, to oprzeć się jego doświadczeniu i zasugerować aktualizację dokumentacji, jeśli stała się myląca. Jeśli powoduje to tarcia, musisz zaapelować do szefa, ponieważ trzymanie jednego standardu na papierze, a drugiego w praktyce (szczególnie na żądanie poszczególnych programistów) jest niezgodne i podważa.

Jednak bardziej prawdopodobne jest, że skupię się na zagrożeniu, które jest skierowane przeciwko tobie. Jeśli zostało to zrobione ustnie, nie masz w tym momencie dobrych dowodów i nie masz dobrej opcji, aby działać w tym momencie, ale będę bardzo ostrożny w stosunku do niego w przyszłości i spróbuję uzyskać wszystko, co powie na piśmie, np. jak najwięcej interakcji za pośrednictwem poczty elektronicznej. Jeśli ponownie zagrozi Ci na piśmie, możesz zacząć rozmawiać o tym z szefem. Sądząc po dźwiękach rzeczy, jego ego jest na tyle kruche, że prędzej czy później znowu będziesz miał z nim problemy.

Problem może się zdarzyć, jeśli nie znasz prawdy z krainy. Jeśli ten facet naprawdę jest tak zły, jak się wydaje, możliwe, że zostały przez niego napisane duże fragmenty kodu i nikt poza nim nie może ich obsługiwać. W związku z tym skutecznie uczynił siebie niepożądanym, ponieważ firma nie może sobie pozwolić na utratę go, co umożliwiło jego kiepskie zachowanie. Może to być dobre w perspektywie krótkoterminowej, jeśli chodzi o bezpieczeństwo pracy, ale w dłuższej perspektywie jest to degeneracja, efekt przeciwny do zamierzonego i może zrujnować Twoją reputację. Nie aspiruj do tego.

Mając to na uwadze, uważaj, aby nie dawać firmie możliwości wyboru, ponieważ interesy firmy będą stawiać na pierwszym miejscu. Traktuj swoją obecną pracę jako doświadczenie w radzeniu sobie z trudnymi ludźmi. Spędź czas z kolegami i dowiedz się, jak sobie radzą z tym facetem, i nie przegap okazji, by nauczyć się od nich innych rzeczy. W międzyczasie miej oko na inne okazje i bądź gotów wylądować na nogach, na wypadek gdyby miał przewagę i wyrzucił cię z powodu innego domniemanego wykroczenia.

Odpowiedź na to w dużej mierze zależy od ogólnego podejścia do „przestrzegania procesów” w firmie i powinieneś już mieć to przeczucie.

Pracowałem w firmie, która była, na papierze, z certyfikatem ISO9001, ale dyrektor generalny zawsze podsłuchiwał nam zapytania ofertowe składane przez szybkie i niekompletne rozmowy telefoniczne, chociaż mieliśmy formularz zapytania, w którym można było zebrać wszystkie informacje. Prawdopodobnie domyślasz się, że w tym przypadku egzekwowanie standardów było przegraną bitwą.

Masz dwie możliwości:

1. Firma ma kulturę przestrzegania procesów : masz rację postępując zgodnie z firmową konwencją kodowania, a jeśli sprawa ulegnie eskalacji, po prostu wyjaśnij, że postępujesz zgodnie ze standardem.
2. Przestrzeganie procesu jest tylko na papierze : zapomnij o instrukcji i postępuj zgodnie z „wskazówką” tego seniora.

„Konwencja kodowania jasno mówi, że mogę zmienić kod, aby był zgodny z duchem konwencji. Konwencja została napisana przez jego bezpośredniego przełożonego”.

Nie mogę przestać myśleć, że to jest straszna dyrektywa. Mimo wszystko oznacza wygenerowanie biletu na „ulepszenie” określonej sekcji kodu lub dostosowanie go do standardu, ale „zmień to, jeśli nie podoba ci się wygląd” to przepis na katastrofę. Jak kontrolujesz te zmiany, gdy są one wprowadzane w ramach innej poprawki? Jak testujesz zmiany?

O ile widzę, twój problem z kodem rówieśników to formalna konwencja kodowania, którą rozumiesz inaczej niż starszy.

Istnieje wiele narzędzi, które automatycznie formatują kod za pomocą zestawu konfigurowalnych reguł. Nie pozostawiają wiele miejsca na interpretację konwencji.

Tak więc podczas regularnego spotkania zespołu (najlepiej retrospektywy scrum) możesz odnieść się do dyskusji z seniorem i powiedzieć, że czujesz się niezadowolony z sytuacji, a następnie zasugerować, aby Twój zespół (a przynajmniej używając takiego automatycznego programu formatującego i wyznacz seniora do skonfigurowania zestawu reguł.

Następnym razem, gdy zmienisz kod seniora (aby naprawić błąd), ponowne formatowanie jest wykonywane przez narzędzie, które skonfigurował. Ciekaw jestem, jak może wtedy obwiniać cię ...