Co zrobić, jeśli współpracownik edytuje kod, aby zmienić jego wygląd?

Co powinieneś zrobić, jeśli współpracownik edytuje Twój kod?

Bez celu dodawania funkcjonalności lub naprawiania błędów, wystarczy zmienić wygląd ...

Porozmawiaj z nimi na ten temat. Przejdź do rozmowy z postawą: „Nie robią tego, aby mnie drażnić lub dlatego, że mają jakąś formę zaburzenia obsesyjno-kompulsywnego; starają się ulepszyć mój kod”.

Ponieważ możesz się mylić. To może być subtelna poprawka i po prostu jej nie zauważyłeś.

Lub może być tak, że istnieje standard kodowania, o którym nie wiesz, że naruszasz, a oni po prostu go poprawiają.

Lub może być tak, że próbują cię zirytować lub mają jakąś formę zaburzenia obsesyjno-kompulsyjnego. Jeśli tak jest, poproś ich, aby przestali, a jeśli to nie zadziała, skontaktuj się z szefem.

Ale nigdy się nie dowiesz, chyba że zapytasz.

Nie jestem tak żonaty, jak mój kod go niepokoi. :) Staram się uczyć od zmian. Czy mój współpracownik dostosował nazwy zmiennych? Napisz bardziej wydajną pętlę? Czy kod jest bardziej czytelny?

Jeśli nie widzę, jak zmiany poprawiły to, co już było, zwykle pytam współpracownika, który je wprowadził, jaka była ich motywacja. Możliwe, że korzyść nie jest dla mnie oczywista. A jeśli mam rację, a oni się mylą, to może wyjaśnię, dlaczego napisałem to tak, jak to zrobiłem.

Jeśli wszystko inne zawiedzie, cofnij odprawę. ;)

Edycja: Wszystkie zakłady są wyłączone, jeśli chęć wprowadzenia kosmetycznych zmian wprowadzi błąd.

IMO ty i twój zespół i tak powinniście stosować standard kodowania. W takim przypadku pytania brzmią: „Czy oryginalny kod był zgodny ze standardem?” Jeśli „tak”, to twój kolega nie powinien dotykać twojego kodu, chyba że zmienisz go funkcjonalnie. Jeśli „nie”, obawiam się, że twój kolega ma pełne prawo do uporządkowania kodu. Jako kierownik projektu cały czas to robię.

Jeśli nie używasz standardu kodowania, cały argument określający „dobry kod” staje się zbyt subiektywny. Dlatego powinieneś używać standardu kodowania :)

Jako jedna z tych osób (osób, które czasami formatują kod innych osób), głównym powodem, dla którego to robię, jest czytelność. Niektóre osoby są po prostu bardzo niechlujne ze swoimi wcięciami lub mieszaniem tabulatorów i spacji.

Najważniejszą rzeczą, którą mam w zwyczaju zmieniać, jest zmniejszanie długich linii, dzięki czemu mogę czytać całość bez przewijania w poziomie. Podzielę złożone instrukcje na osobne instrukcje lub ponownie sformatuję wywołania / deklaracje metod, aby wyświetlić jeden parametr w wierszu, jeśli nie wszystkie wygodnie mieszczą się w jednym wierszu. Będę również edytować komentarze, aby naprawić błędy w języku angielskim lub po prostu, aby wszystko było jaśniejsze.

Tak, mógłbym zostawić to w spokoju, ale wolę zmniejszyć wysiłek umysłowy wymagany do odczytania kodu.

Co powinieneś z tym zrobić? Po pierwsze, zastanów się, że może ta osoba ulepsza Twój kod. Ponadto powinieneś upewnić się, że masz pewien konsens w swoim zespole co do sposobu formatowania kodu. Jeśli każda osoba ma inne nawyki, spowolni wszystkich. Jeśli nie poprawiają twojego kodu i idą wbrew zasadom, musisz stawić im czoła. Jeśli to nie zadziała, być może będziesz musiał zaangażować innych.

Zapytaj ich, dlaczego to robią; prawidłowe wyjaśnienie może zmniejszyć twoją frustrację, ale powinieneś dać im znać, jak bardzo ci to przeszkadza. Kto wie, może myśleli, że wyświadczają ci przysługę i przestaną, gdy się dowiedzą, że cię obraża. Lub możesz mieć do czynienia z kimś, kto naprawdę cierpi na schorzenie.

Czy wolno mu to zrobić? Czy zmiany poprawiają kod? Jeśli tak, połknij swoją dumę. Jeśli uważasz, że jakość kodu uległa pogorszeniu, skontaktuj się ze współpracownikiem i zapytaj go, dlaczego odczuł potrzebę zmiany kodu bez widocznych korzyści. Jeśli dzieje się to z przekleństwem lub dlatego, że osoba błędnie uważa, że ​​jest lepsza od ciebie i nie możesz tego z nimi wypracować, weź to ze swoim szefem.

IDE, podobnie jak Visual Studio, ma opcję o nazwie Format Document, która sformatuje kod zgodnie z regułami ustawionymi przez użytkownika w IDE. Może to być twój współpracownik używa tego (albo automatycznie bez wiedzy, albo przez celową aplikację). Być może ich IDE używa spacji zamiast tabulatorów i odwrotnie, i są one stosowane automatycznie, nawet nie wiedząc? Ale musisz z nimi porozmawiać, aby się dowiedzieć.

Nawiasem mówiąc, często będę ponownie formatować kod współpracowników, jeśli oczywiście nie postępuje zgodnie z jakimś schematem formatowania (tzn. Jest wszędzie). Jest to, miejmy nadzieję, subtelny sposób na ich zauważenie. (Jednak nie sformatowałbym go, gdyby był schludny, ale nie w moim guście).

Jeśli zmieni go tak, aby spełniał standardy kodowania twojego zespołu, powinieneś go przestrzegać następnym razem.

Jeśli zmieni to tak, że nie będzie już zgodne ze standardami kodowania twojego zespołu, poinformuj go, co robi źle, i pozwól mu to zmienić.

... Twój zespół ma zestaw standardów formatowania kodu, z których wszyscy korzystają, prawda?

Czasami zmieniam kod napisany przez niechlujnych współpracowników (lub naprawiam literówki w komentarzach). Wiedzą, że mam obsesję na punkcie formatowania i porządkowania kodu, dlatego pozwalają mi to robić bez narzekania. Czasami dają mi też darmową sodę lub ciasteczko.

Oczywiście jest to praca okazjonalna , ponieważ złamała funkcję „obwiniania” w SVN.

Jest to również bardzo podstawowy sposób na wykonanie przeglądu kodu (zwykle czytam większość kodu popełnionego przez moich współpracowników w modułach, nad którymi pracuję).

Konwencje Code jest odpowiedź. Powinieneś mieć go w pracy. Jeśli nie, zacznij już teraz (dobrym punktem wyjścia jest przewodnik po stylu Google ). Kiedy są zapisane (lub przynajmniej powszechnie znane) reguły, odpowiedź na twoje pytanie jest banalna.

Czuję, że myślisz, że to obraźliwe ...? Na przykład sam bym natychmiast naprawił ten kod

int myFunction( ) {

    int i ;
  return  0;

}

zostać

int myFunction() {
    int i;
    return 0;
}

więc ... czy powinienem zostać ukarany z powodu mojego działania? W rzeczywistości mam mnóstwo dzienników SVN o treści „Formatowanie”. ;-)

Użyj narzędzia do sprawdzania stylu

Zacznij używać StyleCop lub podobnego i egzekwuj reguły stylu kodu, a także nakładaj na wszystkich programistów obowiązek korzystania z niego. Cały kod będzie wyglądał tak samo bez wyjątku. I spotkaj się z mądrymi głowami, aby omówić najbardziej odpowiednie zasady dla Twojej organizacji. Mimo że domyślne reguły są już bardzo podobne do samego kodu frameworku .net.

To najłatwiejszy sposób na zrobienie tego. Zauważyłem, że poprawiam czyjś kod u jednego z moich poprzednich pracodawców, ponieważ ten inny facet pisał kod z nadmierną ilością pustych wierszy i bez żadnych wcięć. Przeciętny programista nie mógł odczytać kodu. Gdyby StyleCop istniał wtedy, wielu z nas byłby naprawdę szczęśliwy.

oto myśl, którą widziałem w Internecie na temat refaktoryzacji i może wyjaśnić, dlaczego ktoś mógłby dotknąć twojego kodu, aby go poprawić:

Dlaczego?

Istnieją dwa główne powody do refaktoryzacji:

1. Aby poprawić kod / projekt przed zbudowaniem go na wierzchu: Naprawdę trudno jest wymyślić dobry kod przy pierwszej próbie. Pierwsza próba wdrożenia dowolnego wstępnego projektu pokaże nam, że źle zinterpretowaliśmy lub zapomnieliśmy trochę logiki.

2. Aby dostosować się do zmian wymagań. Zmiana zachodzi w rozwoju oprogramowania; być wrażliwym na zmiany, lepiej mieć dobrą bazę kodu. Mamy dwie opcje dla obu scenariuszy: ścieżkę do kodu lub refaktoryzację. Łata kodu doprowadzi nas do niemożliwego do utrzymania kodu i zwiększy nasze zadłużenie techniczne, zawsze lepiej jest zrefaktoryzować.

Gdy?

1. Im wcześniej tym lepiej, tym łatwiej.

2. szybsze i mniej ryzykowne dla refaktoryzacji ostatnio zrefaktoryzowanego kodu zamiast oczekiwania na refaktoryzację, aż kod zostanie prawie ukończony.

Co?

1. Cały kod i cały projekt są kandydatami do refaktoryzacji.

2. Wyjątkiem jest brak refaktoryzacji czegoś, co może być działającym fragmentem kodu, którego jakość jest niska, ale z uwagi na fakt, że zbliża się termin, wolimy utrzymać nasz dług techniczny niż ryzykować planizację.

Musisz po prostu pozwolić mu dać z siebie wszystko, jeśli byłoby to świetne dla obu i zaoszczędzić czas w przyszłości!

Twoje zdrowie