Meldowanie kodu „zakomentowanego” [zamknięte]

Ok, jest coś, co spowodowało pewne tarcia w mojej obecnej pracy i naprawdę się tego nie spodziewałem. Zorganizowane we własnym zakresie tworzenie oprogramowania jest tutaj nową koncepcją. Przygotowałem pierwszy szkic kilku wskazówek dotyczących kodowania.

Zaproponowałem, aby kod „wykomentowany” nigdy nie był wpisywany do repozytorium. Powodem, dla którego to stwierdziłem, jest to, że repozytorium przechowuje pełną historię plików. Jeśli usuwasz kod funkcjonalny, usuń go całkowicie. Repozytorium przechowuje Twoje zmiany, więc łatwo jest zobaczyć, co zostało zmienione.

Spowodowało to pewne tarcia, ponieważ inny programista uważa, że ​​obranie tej drogi jest zbyt restrykcyjne. Ten programista chciałby móc skomentować kod, nad którym pracuje, ale jest niekompletny. Ten kod nigdy nie zostałby wcześniej zarejestrowany, a następnie nigdzie nie zostałby zapisany. Będziemy używać TFS, więc zasugerowałem, że najodpowiedniejszym rozwiązaniem byłoby wstrzymanie zmian. Nie został jednak zaakceptowany, ponieważ chciałby mieć możliwość sprawdzania częściowych zmian, które mogą, ale nie muszą, zostać wdrożone.

Chcemy w końcu dojść do punktu, w którym będziemy w pełni wykorzystywać ciągłą integrację i automatycznie wdrażać ją na programistycznym serwerze WWW. Obecnie nie ma wersji rozwojowej serwerów WWW ani baz danych, ale wkrótce wszystko się zmieni.

W każdym razie, co myślisz? Czy uważasz, że „wykomentowany” kod jest przydatny w repozytorium?

Jestem bardzo zainteresowany wiadomościami na ten temat od innych.

Edycja: ze względu na przejrzystość nie używamy oddziałów prywatnych. Gdybyśmy tak zrobili, powiedziałbym, że rób, co chcesz ze swoim prywatnym oddziałem, ale nigdy nie łącz zakomentowanego kodu z linią główną lub innymi gałęziami współdzielonymi.

Edycja: nie ma żadnego uzasadnionego powodu, dla którego nie używamy oddziałów prywatnych ani dla użytkowników. To nie jest koncepcja, z którą się nie zgadzam. Po prostu jeszcze tego nie ustawiliśmy. Być może jest to ostateczny środek. Na razie używamy regałów TFS.

Mogą być inni z różnymi doświadczeniami, ale u mnie sprawdzanie niedokończonego kodu to okropny pomysł, kropka.

Oto zasady, których się nauczyłem i których staram się przestrzegać:

• Melduj się często - przynajmniej raz, ale najlepiej wiele razy dziennie
• Sprawdź tylko pełną funkcjonalność
• Jeśli pierwszy i drugi konflikt (np. Uruchomienie funkcjonalności zajmuje więcej niż jeden dzień), to zadanie jest zbyt duże - podziel je na mniejsze zadania do wykonania.

To znaczy:

• Skomentowany kod nigdy nie powinien być rejestrowany, ponieważ nie działa
• Komentowanie nie jest poprawną strategią archiwizacji, więc niezależnie od tego, czy jest to kod jeszcze nieukończony, czy kod, który jest wycofywany, komentowanie i sprawdzanie nie ma żadnego sensu.

Podsumowując, NIE! Jeśli kod nie jest gotowy, aby przejść do następnego etapu (niezależnie od tego, który jest dla Ciebie: IntTest / QA / UAT / PreProd / Prod), nie powinien być przypisywany do gałęzi trunk lub multi-developer. Kropka.

Edycja: Po przeczytaniu innych odpowiedzi i komentarzy dodam, że nie sądzę, aby koniecznie zbanować skomentowany kod (i tak nie jestem pewien, jak chcesz to wymusić). Powiem tylko, że powinieneś nakłonić wszystkich w swoim zespole do przyjęcia filozofii, którą opisałem powyżej. Zespół, nad którym pracuję, przyjmuje to całym sercem. W rezultacie kontrola źródła to beztroski członek zespołu, który pomaga nam wykonywać naszą pracę.

Osoby, które nie przyjmują tej filozofii, zwykle powodują rozbite okna i często frustrują się z powodu kontroli źródła. W najlepszym przypadku postrzegają to jako zło konieczne, aw najgorszym należy unikać; co prowadzi do rzadkich meldowań, co oznacza, że ​​zestawy zmian są ogromne i trudne do scalenia, co potęguje frustrację, sprawia, że ​​meldunki są czymś, czego należy unikać jeszcze bardziej itd. Ostatecznie jest to kwestia nastawienia, a nie procesu. Łatwo jest postawić przeciwko temu mentalne bariery; łatwo jest znaleźć powody, dla których to nie zadziała, podobnie jak łatwo jest znaleźć powody, aby nie stosować diety, jeśli tak naprawdę nie chcesz. Ale kiedy ludzie nie chcą tego robić i są zobowiązane do zmiany swoich nawyków, wyniki są dramatyczne. Musisz skutecznie go sprzedać.

„Nigdy” rzadko jest dobrym słowem w wytycznych.

Twój kolega ma świetny przykład, kiedy warto wpisać kod, który jest zakomentowany: Kiedy jest niekompletny i może zepsuć aplikację, jeśli jest zarejestrowana, gdy jest aktywna.

W większości przypadków komentowanie martwego kodu nie jest konieczne w dobrze zarządzanym systemie z kontrolą zmian. Jednak nie każdy kod komentowany jest „martwy”.

Skomentowany kod nigdy nie powinien być rejestrowany w celu zachowania historii. To jest punkt kontroli źródła.

Ludzie mówią tutaj o wielu ideałach. Być może w przeciwieństwie do wszystkich, muszę pracować nad wieloma projektami z wieloma przerwami, w których „prawdziwy świat” od czasu do czasu przeszkadzał mi w pracy.

Czasami rzeczywistość jest taka, że ​​muszę zarejestrować częściowo kompletny kod. Istnieje ryzyko utraty kodu lub zaewidencjonowania niekompletnego kodu. Nie zawsze mogę sobie pozwolić na „dokończenie” zadania, nieważne jak małe. Ale nie odłączę laptopa od sieci bez wpisania całego kodu.

W razie potrzeby utworzę własną gałąź roboczą, aby dokonać częściowych zmian.

Jeden przypadek, w którym zostawiam wykomentowany kod:

// This approach doesn't work
// Blah, blah, blah

kiedy jest to oczywiste podejście do problemu, ale zawiera ono jakąś subtelną wadę. Jasne, repozytorium by to miało, ale repozytorium nie ostrzegałoby nikogo w przyszłości, aby nie szedł tą drogą.

Z pewnością zdecydowanie odradzałbym kiedykolwiek sprawdzanie skomentowanego kodu. Nie zakazałbym jednak tego absolutnie. Czasami (jeśli rzadko) warto sprawdzić przekomentowany kod w kontroli źródła. Powiedzenie „nigdy tego nie rób” jest zbyt restrykcyjne.

Myślę, że wszyscy zgadzamy się z następującymi punktami:

• Nigdy nie sprawdzaj martwego kodu w kontroli źródła
• Nigdy nie sprawdzaj zepsutego (niedziałającego) kodu w kontroli źródła, przynajmniej nigdy do łącza trunk i tylko bardzo rzadko do oddziału prywatnego, YMMV
• Jeśli tymczasowo coś zakomentowałeś lub zepsułeś coś w celu debugowania, nie sprawdzaj kodu, dopóki nie przywrócisz go do poprawnej formy

Niektórzy mówią, że istnieją inne kategorie, takie jak tymczasowo usunięty kod lub przyrostowe, ale niekompletne ulepszenia, które obejmują niewielką ilość zakomentowanego kodu jako dokumentację tego, co będzie dalej, lub bardzo krótki (najlepiej 1 wiersz) fragment komentowanego kod pokazujący coś, czego nigdy nie należy ponownie dodawać. Skomentowany kod powinien ZAWSZE być opatrzony komentarzem, który mówi, dlaczego jest komentowany (a nie tylko usuwany) i podaje oczekiwany czas życia zakomentowanego kodu. Na przykład „Poniższy kod wyrządza więcej szkody niż pożytku, więc jest komentowany, ale musi zostać zastąpiony przed udostępnieniem XXX”.

Komentarz taki jak powyższy jest odpowiedni, jeśli dostarczasz poprawkę, która ma zatrzymać krwawienie klienta i nie masz natychmiastowej możliwości znalezienia ostatecznej poprawki. Po dostarczeniu poprawki, zakomentowany kod przypomina, że ​​wciąż masz coś do naprawienia.

Kiedy mam wpisać zakomentowany kod? Jednym z przykładów jest sytuacja, w której wstępnie usuwam coś, co, jak sądzę, z dużym prawdopodobieństwem będzie musiało zostać ponownie dodane w najbliższej przyszłości w jakiejś formie. Zakomentowany kod ma służyć jako bezpośrednie przypomnienie, że jest niekompletny. Jasne, stara wersja jest w kontroli źródła i możesz po prostu użyć komentarza FIXME jako flagi, że potrzeba czegoś więcej. Jednak czasami (jeśli nie często) kod jest lepszym komentarzem.

Ponadto, gdy błąd zostanie naprawiony poprzez usunięcie jednego wiersza (lub rzadziej dwóch) kodu, czasami po prostu komentuję wiersz z komentarzem, aby nigdy ponownie nie włączać tego kodu z podaniem powodu. Ten rodzaj komentarza jest jasny, bezpośredni i zwięzły.

Rex M powiedział: 1) Sprawdź tylko pełną funkcjonalność, 2) [Jeśli] zadanie jest zbyt duże - podziel je na mniejsze zadania do wykonania.

W odpowiedzi: tak, to jest ideał. Czasami żadna opcja nie jest dostępna, gdy pracujesz nad kodem produkcyjnym i masz natychmiastowy krytyczny problem do naprawienia. Czasami, aby wykonać zadanie, musisz na chwilę umieścić w polu wersję kodu. Jest to szczególnie ważne w przypadku zmian kodu gromadzenia danych, gdy próbujesz znaleźć główną przyczynę problemu.

W przypadku konkretnego przypadku, o który pytamy w bardziej ogólnym pytaniu ... o ile programista sprawdza zakomentowany kod w prywatnej gałęzi, której nikt nie zobaczy oprócz tego programisty (i być może kogoś, z kim współpracuje), to niewiele szkodzi. Ale ten programista (prawie) nigdy nie powinien dostarczać takiego kodu do magistrali lub odpowiednika. Tułów powinien zawsze się budować i zawsze funkcjonować. Dostarczanie niedokończonego kodu do łącza trunk jest prawie zawsze bardzo złym pomysłem. Jeśli pozwolisz programiście sprawdzić niedokończony lub tymczasowy kod w gałęzi prywatnej, musisz polegać na deweloperze, aby nie zapomniał wyczyścić kodu przed dostarczeniem do linii głównej.

Aby wyjaśnić w odpowiedzi na komentarze do innych odpowiedzi, jeśli kod zostanie zakomentowany i zaewidencjonowany, moje oczekiwanie, że kod będzie działał, jeśli niekomentowany spadnie wraz z długością czasu, w którym kod był komentowany. Oczywiście narzędzia do refaktoryzacji nie zawsze będą zawierać komentarze w procesie refaktoryzacji. Prawie zawsze, gdy wprowadzam do produkcji kod wykomentowany, kod ma służyć jako dopracowany komentarz, coś bardziej konkretnego niż proza, że ​​coś tam trzeba zrobić. To nie jest coś, co powinno mieć długie życie.

Wreszcie, jeśli możesz znaleźć przekomentowany kod w każdym pliku źródłowym, coś jest nie tak. Dostarczanie zakomentowanego kodu do łącza trunk z jakiegokolwiek powodu powinno być rzadkim zdarzeniem. Jeśli zdarza się to często, staje się zagracony i traci swoją wartość.

Myślę, że nigdy nie jest to zbyt silny stan.

Zwykle komentuję, sprawdzam, przeprowadzam testy, zastanawiam się, a następnie usuwam komentarze po następnym wydaniu.

Ogólnie rzecz biorąc, wpisywanie skomentowanego kodu jest niewłaściwe, ponieważ powoduje zamieszanie wśród tych, którzy nie są oryginalnymi autorami i muszą przeczytać lub zmienić kod. W każdym razie oryginalny autor często po upływie 3 miesięcy jest zdezorientowany co do kodu.

Wyrażam przekonanie, że kod należy do firmy lub zespołu i że Twoim obowiązkiem jest ułatwienie pracy innym osobom. Wpisanie zakomentowanego kodu bez dodania komentarza o tym, dlaczego jest przechowywany, jest równoznaczne z powiedzeniem:

Nie mam nic przeciwko, jeśli zdezorientujesz się, dlaczego te rzeczy są tutaj. Moje potrzeby są ważniejsze niż Twoje, dlatego to zrobiłem. Nie czuję potrzeby usprawiedliwiania Tobie ani nikomu innemu, dlaczego to zrobiłem.

Dla mnie kod skomentowany jest zwykle postrzegany jako oznaka braku szacunku ze strony mniej rozważnego współpracownika.

Kiedy potrzebujesz dodać małą funkcję lub poprawkę błędu, jak TERAZ, w ciągu najbliższych 3 minut i musisz naprawić plik, na którym masz w połowie opracowany kod, powiedziałbym, że jest w porządku, potrzeby praktyczne rządzą pragmatycznymi ideałami na polu bitwy.

Generalnie zgadzam się z zasadą, że zakomentowany kod nie powinien być sprawdzany. System kontroli wersji jest zasobem współdzielonym, a Twój kolega do pewnego stopnia używa go jako osobistego notatnika. Nie jest to zbyt ważne dla innych użytkowników, szczególnie jeśli zgadzasz się z ideą współdzielenia własności bazy kodu.

Następny programista, który zobaczy ten przekomentowany kod, nie miałby pojęcia, że ​​jest to w toku. Czy może to zmienić? Czy to martwy kod? On nie wie.

Jeśli zmiana Twojego kolegi nie jest w stanie, w którym można ją zarejestrować, musi ją dokończyć i / lub nauczyć się wprowadzać mniejsze, przyrostowe zmiany.

„Sprawdzanie częściowych zmian, które mogą lub nie mogą zostać wdrożone” - przypuszczalnie oznacza to również, że mogą lub nie mogą być testowane? To śliskie zbocze do bardzo niepewnej podstawy kodu.

Pokazuje to zasadniczą różnicę w dwóch szkołach myślenia: ci, którzy sprawdzają działający kod, z którego są zadowoleni i czują, że są godni uratowania, oraz ci, którzy sprawdzają swoją pracę, aby kontrola wersji była po to, aby zabezpieczyć ich przed utratą danych.

Tych ostatnich scharakteryzowałbym jako „tych, którzy lubią używać swojego systemu kontroli wersji jako kopii zapasowej na taśmie biedaka”, ale to byłoby wskazanie ręki, w którym obozie jestem. :-)

Przypuszczam, że należysz do obozu „dobrego kodowania”, a on jest z obozu „kodeks pracy”.

[EDYTOWAĆ]

Z komentarzy, tak, zgadłem.

Jak powiedziałem, jestem z tobą, ale tak blisko, jak mogę powiedzieć, jest to opinia mniejszości, zarówno tutaj na temat stackoverflow, jak i tam, gdzie pracuję. W związku z tym nie sądzę, aby można było zapisać to w swoich standardach rozwoju jako jedyny sposób działania. Nie, jeśli chcesz, aby standardy były przestrzegane. Dobry przywódca wie tylko, że nigdy nie wydaje rozkazów, o których wiedzą, że nie będą przestrzegane.

btw: Dobrzy redaktorzy pomogą w zachowaniu starych wersji. Na przykład w Emacsie ustawiłem zachowane-stare-wersje i zachowane-stare-wersje na 10, co oznacza, że ​​zachowuje około 10 ostatnich zapisów moich plików. Możesz potraktować to jako sposób na pomoc w argumentacji przeciwko tłumowi kontroli wersji jako kopii zapasowej. Jednak nigdy nie wygrasz sporu.

Z mojego doświadczenia wynika, że ​​przełączniki programistyczne są wykomentowane w kodzie.

Czasami nowe zaplecze są budowane równolegle, a przełączniki aktywujące są komentowane w kontroli źródła.

Niektóre dziwne funkcje, których potrzebujemy kiedyś na niebieskim księżycu, ale żaden klient nigdy nie będzie potrzebował, są często wdrażane w ten sposób. Te rzeczy zwykle wiążą się z wysokim ryzykiem obejścia bezpieczeństwa lub integralności danych, więc nie chcemy, aby były aktywne poza programowaniem. Wymaganie od programisty, który użyłby go najpierw odkomentowania kodu, wydaje się być najłatwiejszym sposobem na jego uzyskanie.

Kolejny powód wpisania zakomentowanego kodu:

Modyfikujesz istniejący kod i znalazłeś subtelny błąd, który można łatwo przeoczyć, a na pierwszy rzut oka może nawet wyglądać poprawnie. Skomentuj to, umieść poprawkę na swoim miejscu i dodaj komentarze do tego, co się dzieje i dlaczego została zmodyfikowana. Zaznacz to, aby Twoje komentarze dotyczące poprawki były w repozytorium.

Być może prawdziwe pytanie brzmi, czy programiści powinni mieć możliwość sprawdzenia niekompletnego kodu?

Ta praktyka wydaje się być sprzeczna z twoim celem, jakim jest wdrożenie ciągłej integracji.

To zależy. Może jeśli zostanie tam w celach ilustracyjnych. Może to być przydatne podczas refaktoryzacji. W przeciwnym razie i ogólnie nie. Ponadto komentowanie niedokończonego kodu jest z pewnością podatne na awarie i pochłania czas. Lepiej, żeby podzielił kod na mniejsze części i sprawdzał je, gdy działają.

Mój pogląd: jeśli programiści pracują nad własnymi oddziałami lub we własnym obszarze piaskownicy, powinni mieć możliwość sprawdzania, co chcą. To wtedy, gdy sprawdzają kod we współdzielonej gałęzi (gałąź funkcji, gałąź zespołu lub oczywiście MAIN / trunk), kod powinien być tak czysty, jak to tylko możliwe (bez kodu zakomentowanego, koniec z FIXME itp.).

Myślę, że „nigdy” to zbyt mocna zasada. Głosowałbym za pozostawieniem osobistej swobody, czy ludzie sprawdzają skomentowany kod w repozytorium. Ostatecznym celem powinna być produktywność programisty, a nie „czyste repozytorium”.

Aby zrównoważyć tę rozluźnienie, upewnij się, że wszyscy wiedzą, że zakomentowany kod ma datę ważności. Każdy może usunąć skomentowany kod, jeśli był w pobliżu przez cały tydzień i nigdy nie był aktywny. (Zastąp „tydzień” tym, co uważasz za właściwe). W ten sposób zastrzegasz sobie prawo do zabicia bałaganu, gdy go zobaczysz, bez zbytniego ingerowania w osobisty styl ludzi.

Absolutnie zgadzam się, że zakomentowany kod nie powinien być wpisywany do repozytorium, do tego służy kontrola kodu źródłowego.

Z mojego doświadczenia wynika, że ​​programista sprawdza zakomentowany kod, ponieważ nie jest pewien, jakie jest właściwe rozwiązanie i jest szczęśliwszy, pozostawiając alternatywne rozwiązanie w źródle w nadziei, że ktoś inny podejmie taką decyzję.

Uważam, że komplikuje kod i utrudnia czytanie.

Nie mam problemu ze sprawdzeniem w połowie ukończonego kodu (dzięki czemu uzyskujesz korzyść z kontroli źródła), który nie jest wywoływany przez system na żywo. Mój problem polega na znalezieniu sekcji komentowanego kodu bez wyjaśnienia, dylemat polegał na tym, że kod został wykluczony.

Myślę, że wpisywanie komentowanego kodu w systemie kontroli kodu źródłowego powinno odbywać się z dużą ostrożnością, zwłaszcza jeśli tagi językowe używane do komentowania kodu są pisane blokami, tj .:

/* My commented code start here
My commented code line 1
My commented code line 2
*/

Zamiast na zasadzie indywidualnej linii, na przykład:

// My commented code start here
// My commented code line 1
// My commented code line 2

(Masz pomysł)

Powodem, dla którego chciałbym zachować szczególną ostrożność, jest to, że w zależności od technologii należy bardzo uważać na używane narzędzie porównywania / scalania. W przypadku określonego systemu kontroli kodu źródłowego i określonego języka narzędzie porównywania / scalania można łatwo pomylić. Na przykład standardowe porównywanie / scalanie ClearCase jest notorycznie złe w przypadku łączenia plików .xml.

Jeśli zdarzy się, że komentujące wiersze bloków nie zostaną prawidłowo scalone, presto twój kod stanie się aktywny w systemie, a nie powinien. Jeśli kod jest niekompletny i zepsuje kompilację, jest to prawdopodobnie najmniej złe, ponieważ natychmiast to zauważysz.

Ale jeśli kod przejdzie kompilację, może stać się aktywny, gdy nie powinno go tam być, az punktu widzenia CM może to być koszmar. QA ogólnie testuje, co powinno tam być, nie testują kodu, którego nie powinno tam być, więc twój kod może skończyć w produkcji, zanim się zorientujesz, a zanim zostanie zrealizowany, kod jest tam, kiedy się pojawi nie powinno, koszt utrzymania zwielokrotnił wiele razy (ponieważ „błąd” zostanie wykryty w produkcji lub przez klienta, w najgorszym miejscu lub czasie).

Pomysł, by pozwolić historii kontroli źródła na zilustrowanie „starego sposobu” robienia czegoś, zamiast komentować to i sprawdzać w komentarzach wraz z wyjaśnieniem, jest dobrym pomysłem w teorii.

Jednak w prawdziwym świecie nikt nigdy nie patrzy na historię kontroli źródła plików, nad którymi pracują, chyba że jest to część oficjalnego procesu przeglądu (wykonywanego tylko okresowo) lub jeśli coś nie działa, a programista nie mogę zrozumieć, dlaczego.

Nawet wtedy przeglądanie więcej niż trzech wersji w zasadzie nigdy się nie zdarza.

Częściowo dzieje się tak dlatego, że systemy kontroli źródła nie ułatwiają tego rodzaju przypadkowego przeglądu. Zwykle musisz sprawdzić starą wersję lub różnicę w stosunku do starej wersji, po prostu widzisz dwie wersje i nie ma dobrego, zwięzłego obrazu tego, co się zmieniło, co mogłoby dać ci natychmiastowe wyobrażenie o tym, co się zmieniło.

Po części jest to połączenie natury ludzkiej i potrzeb zespołu. Jeśli muszę coś naprawić i mogę to naprawić w ciągu kilku godzin, prawdopodobnie nie spędzę godziny na badaniu starych wersji kodu, które nie były „aktywne” od miesiąca (co przy sprawdzaniu przez każdego programistę często oznacza wstecz wiele poprawek), chyba że przypadkiem wiem, że coś w tym jest (na przykład, gdy pamiętam dyskusję o zmianie czegoś związanego z tym, co teraz robię).

Jeśli kod zostanie usunięty i ponownie wpisany, to ze wszystkich zamiarów i celów (z wyjątkiem ograniczonego celu całkowitego wycofania) przestaje istnieć. Tak, jest tam jako kopia zapasowa, ale bez osoby w roli bibliotekarza kodu zaginie.

Moje drzewo kontroli źródła w moim obecnym projekcie ma około 10 tygodni, składa się z zespołu tylko około 4 inżynierów i jest około 200 zatwierdzonych list zmian. Wiem, że mój zespół nie radzi sobie tak dobrze, jak powinien, polegając na sprawdzaniu, gdy tylko pojawi się coś solidnego i gotowego do pracy. To sprawia, że ​​poleganie na czytaniu historii kodu dla każdej części kodu w celu wychwycenia każdej ważnej zmiany jest dość trudne.

Obecnie pracuję nad projektem w trybie początkowego rozwoju, który bardzo różni się od projektu w trybie konserwacji. Wiele takich samych narzędzi jest używanych w obu środowiskach, ale potrzeby znacznie się różnią. Na przykład często zdarza się, że zadanie wymaga od dwóch lub więcej inżynierów bliskiej współpracy, aby coś zbudować (powiedzmy, klient i jakiś serwer).

Jeśli piszę serwer, mógłbym napisać kod dla wersji roboczej interfejsu, z którego klient będzie korzystał, i sprawdzić go jako całkowicie niefunkcjonalny, tak aby inżynier piszący klienta mógł zaktualizować. Dzieje się tak, ponieważ mamy zasadę, która mówi, że jedynym sposobem wysłania kodu od jednego inżyniera do drugiego jest użycie systemu kontroli źródła.

Jeśli zadanie będzie trwało wystarczająco długo, warto byłoby stworzyć gałąź, nad którą moglibyśmy pracować we dwoje (choć jest to sprzeczne z polityką w mojej organizacji - inżynierowie i poszczególni kierownicy zespołów nie mają niezbędnych uprawnień serwer kontroli źródła). Ostatecznie jest to kompromis, dlatego staramy się nie wprowadzać zbyt wielu polityk „zawsze” lub „nigdy”.

Prawdopodobnie zareagowałbym na taką politykę bez komentowania kodu, mówiąc, że była trochę naiwna. Być może w dobrych intencjach, ale ostatecznie jest mało prawdopodobne, aby osiągnąć swój cel.

Chociaż zobaczenie tego posta sprawi, że wrócę przez kod, który sprawdziłem w zeszłym tygodniu i usuniemy zakomentowaną część, która nigdy nie była ostateczna (chociaż zadziałała) i prawdopodobnie nigdy nie będzie pożądana.

Myślę, że zakomentowany kod jest uważany za „marnotrawstwo”.

Zakładam, że pracujesz w środowisku zespołowym. Jeśli pracujesz samodzielnie i wykomentujesz kod za pomocą „todo” i wrócisz do tego, to jest inaczej. Ale w środowisku zespołowym możesz bezpiecznie założyć, że skomentowany kod zostanie sprawdzony, że pozostanie i najprawdopodobniej spowoduje więcej bólu niż satysfakcji.

Jeśli robisz recenzje kodu rówieśniczego, może to odpowiedzieć na twoje pytanie. Jeśli inny programista przegląda Twój kod i mówi „dlaczego istnieje ten przekomentowany kod, który próbuje wykonać„ bla ””, oznacza to, że kod nie przeszedł weryfikacji i i tak nie powinieneś go sprawdzać.

Skomentowany kod po prostu wywoła pytania innych programistów - w ten sposób marnując czas i energię.

Musisz zadać pytanie „ dlaczego ” kod jest wykomentowany. Jakieś sugestie:

Jeśli komentujesz kod, ponieważ nie jesteś „pewien reguł biznesowych”, prawdopodobnie masz problem z „pełzaniem zakresu” - najlepiej nie brudzić swojej bazy kodu wymaganiami, które „byłoby fajnie mieć, ale nie mamy czasu implementować ”- utrzymuj go w czystości dzięki przejrzystemu kodowi i testom na temat tego, co faktycznie tam jest.

Jeśli komentujesz kod, ponieważ nie jesteś „pewien, czy jest to najlepszy sposób na zrobienie tego”, poproś o sprawdzenie swojego kodu przez innych! Czasy się zmieniają, spojrzysz na kod, który napiszesz dziś za 2 lata i pomyślisz, że to okropne! Ale nie możesz komentować fragmentów, które „wiesz”, można zrobić lepiej, ale po prostu nie możesz teraz znaleźć sposobu. Niech ktokolwiek utrzymuje bazę kodu przez długi czas, zdecyduje, czy istnieje lepszy sposób - po prostu przygotuj kod napisany, przetestowany i działający i idź dalej.

Jeśli komentujesz kod, ponieważ „coś nie działa”, NAPRAW TO ! Typowy scenariusz to „zepsute testy” lub „zadania do zrobienia” . Jeśli je posiadasz, zaoszczędzisz dużo czasu, naprawiając je lub po prostu się ich pozbywając. Jeśli można je „złamać” przez jakiś czas, najprawdopodobniej mogą zostać złamane na zawsze.

Wszystkie te potencjalne scenariusze (i te, o których tutaj nie wspomniałem) to strata czasu i wysiłku. Skomentowany kod może wydawać się małym problemem, ale może wskazywać na większy problem w Twoim zespole.

Repozytoria to kopia zapasowa kodu. Jeśli pracuję nad kodem, ale nie jest on ukończony, może go skomentować i sprawdzić na koniec dnia. W ten sposób, jeśli mój dysk twardy umrze z dnia na dzień, nie stracę żadnej pracy. Mogę rano sprawdzić kod, odkomentować go i kontynuować.

Jedynym powodem, dla którego chciałbym to skomentować, jest to, że nie chciałbym zepsuć tej nocnej kompilacji.

Istnieje wyraźna różnica między 1) wczesnym sprawdzaniem a 2) ciągłym utrzymywaniem repozytorium w stanie roboczym. Jeśli masz więcej niż kilku programistów, ten ostatni będzie miał coraz większe znaczenie, ponieważ nie możesz mieć jednego programisty, który bzdurałby wszystkich innych dla własnego przepływu pracy. To powiedziawszy , nie należy lekceważyć wartości pierwszej wskazówki. Programiści używają różnego rodzaju mentalnych słupków, a zindywidualizowane przepływy pracy są jednym ze sposobów, w jaki wielcy programiści wyciskają te dodatkowe X-y. Jako menedżer Twoim zadaniem jest nie próbować zrozumieć wszystkich tych niuansów - co nie powiedzie ci, chyba że jesteś geniuszem, a wszyscy twoi programiści są idiotami - ale raczej pozwól swoim programistom być najlepszymi, jak potrafią, poprzez własne podejmowanie decyzji.

Wspomniałeś w komentarzu, że nie korzystasz z oddziałów prywatnych. Moje pytanie do Ciebie brzmi: dlaczego nie? Okej, nie wiem nic o TFS, więc może są dobre powody. Jednak po roku używania git, muszę powiedzieć, że dobry DVCS całkowicie rozprasza to napięcie. Są przypadki, w których wykomentowanie kodu jest przydatne podczas budowania zamiennika, ale stracę nad tym sen, jeśli narzucę go innym. Możliwość rozgałęziania się lokalnie oznacza, że ​​mogę zachować znaczące zatwierdzenia dla mojego indywidualnego procesu bez martwienia się (lub nawet powiadamiania) dalszych deweloperów o tymczasowych błędach.

Powtarzam tylko refren. Zniechęcaj do tego za wszelką cenę. To sprawia, że ​​kod jest trudniejszy do odczytania i pozostawia ludzi zastanawiających się, co jest dobrego / złego w kodzie, który obecnie nie jest nawet częścią aplikacji. Zawsze możesz znaleźć zmiany, porównując wersje. Jeśli była jakaś poważna operacja i kod był masowo komentowany, programista powinien był to odnotować w uwagach do rewizji przy sprawdzaniu / scalaniu.

niekompletny / eksperymentalny kod powinien znajdować się w gałęzi, która ma być rozwijana do końca. głowa / tułów powinna być główną linią, która zawsze się kompiluje i jest wysyłana. gdy gałąź eksperymentalna zostanie ukończona / zaakceptowana, powinna zostać scalona z nagłówkiem / linią główną. Istnieje nawet norma IEEE (IEEE 1042) opisująca to, jeśli potrzebujesz dokumentacji pomocniczej.

Wolałbym, aby prawdopodobnie uszkodzony, dostępny kod, który nie jest jeszcze używany, został zarejestrowany, a ten sam kod jest całkowicie niedostępny. Ponieważ wszystkie programy do kontroli wersji pozwalają na jakąś „kopię roboczą” niezależnie od pnia, o wiele lepszym pomysłem jest użycie tych funkcji.

Nowy, niefunkcjonalny kod jest w porządku w bagażniku, ponieważ jest nowy. Prawdopodobnie nie psuje niczego, co już działa. Jeśli złamie działający kod, powinien po prostu przejść do gałęzi, aby inni programiści mogli (jeśli muszą) sprawdzić tę gałąź i zobaczyć, co jest zepsute.

„ Tkanka blizny ” to kod, który nazywam wykomentowanym. W czasach poprzedzających powszechne stosowanie systemów kontroli wersji, Code Monkeys pozostawiały zakomentowany kod w pliku na wypadek konieczności przywrócenia funkcjonalności.

Jedynym momentem, w którym dopuszczalna jest rejestracja „tkanki bliznowatej” jest

1. Jeśli masz oddział prywatny i
2. Nie masz czasu na kompilację kodu bez błędów i
3. Jedziesz na długie wakacje i
4. Nie ufasz swojemu VCS, na przykład jeśli używasz Visual Source Safe OR .
   [EDYTOWAĆ]
5. Masz subtelny błąd, który może zostać ponownie wprowadzony, jeśli niepoprawny kod nie zostanie pozostawiony jako przypomnienie. (dobra uwaga z innych odpowiedzi).

Nie ma prawie żadnego usprawiedliwienia dla # 4, ponieważ istnieje wiele swobodnie dostępnych i solidnych systemów VCS, a Git jest najlepszym przykładem .

W przeciwnym razie pozwól VCS być dystrybutorem Twojego archiwum i kodu. Jeśli inny programista chce spojrzeć na Twój kod, wyślij mu e-mailem różnice i pozwól mu bezpośrednio zastosować to, czego chce. W każdym razie przy scalaniu nie ma znaczenia, dlaczego i jak rozeszło się kodowanie dwóch plików.

Ponieważ jest to kod, blizny mogą być bardziej rozpraszające, nawet niż dobrze napisany komentarz. Z samej swej natury kodu, programista konserwujący zużywa mentalne cykle procesora na zastanawianie się, czy blizna ma cokolwiek wspólnego z jego zmianami. Nie ma znaczenia, czy blizna ma tydzień, czy 10 lat, pozostawienie tkanki bliznowatej w kodzie stanowi obciążenie dla tych, którzy muszą rozszyfrować kod posłowie.

[EDYCJA] Dodam, że istnieją dwa główne scenariusze, które należy rozróżnić:

• rozwój prywatny, albo kodowanie własnego projektu, albo meldowanie się w oddziale prywatnym
• Rozwój utrzymania, w którym sprawdzany kod ma zostać wprowadzony do produkcji.

Po prostu powiedz „NIE” blizny!

Nie wiem - zawsze komentuję oryginalne wiersze przed wprowadzeniem zmian - pomaga mi to cofnąć je, jeśli zmienię zdanie. I tak, sprawdzam je.

Usuwam jednak stary skomentowany kod z poprzedniego zameldowania.

Wiem, że mógłbym spojrzeć na dzienniki różnic, aby zobaczyć, co się zmieniło, ale jest to uciążliwe - miło jest zobaczyć ostatnie zmiany w kodzie.

Miłym kompromisem jest napisanie małego narzędzia, które zrzuca wyewidencjonowane / zmodyfikowane pliki na sieciowy dysk kopii zapasowej. W ten sposób możesz modyfikować zawartość swojego serca i mieć kopię zapasową swojej pracy, ale nigdy nie musisz sprawdzać kodu eksperymentalnego lub niedokończonego.

Myślę, że sprawdzanie w wykomentowanym kodzie powinno być poprawne, ponieważ tylko dlatego, że nowa zmiana przeszła testy, może być bardziej pomocne, aby zobaczyć, co było wcześniej i zobaczyć, czy nowa zmiana jest naprawdę ulepszeniem.

Gdybym musiał cofnąć się o kilka wersji, aby zobaczyć wcześniejszą zmianę, która teraz prowadzi do uderzenia w wydajność, byłoby to bardzo denerwujące.

Czasami zakomentowany kod jest dobrą historią, ale podaj daty, kiedy kod został skomentowany. Później ktoś, kto pracuje w pobliżu, może po prostu usunąć zakomentowany kod, ponieważ okazało się, że nie jest potrzebny.

Dobrze byłoby również wiedzieć, kto skomentował ten kod, aby można było zapytać, czy potrzebne jest jakieś uzasadnienie.

Wolę napisać nową funkcjonalność, upewnić się, że testy jednostkowe przeszły pomyślnie, sprawdzić, a następnie pozwolić innym na użycie i zobaczyć, jak to działa.

Jeśli programista zakomentował jakiś kod, ponieważ nie jest jeszcze kompletny, wówczas prawidłowym sposobem „kontroli źródła” byłoby zachowanie go w osobnej gałęzi, dopóki ten kod nie będzie gotowy do sprawdzenia w.

Z DVCS (takim jak git, bazaar lub mercurial) jest to banalnie proste, ponieważ nie wymaga żadnych zmian w centralnym repozytorium. W przeciwnym razie możesz porozmawiać o udostępnieniu deweloperom własnych oddziałów na serwerze, jeśli pracują nad określonymi funkcjami, co zajmie im wystarczająco dużo czasu (np. Dni).

Nie ma nic złego w sprawdzaniu skomentowanego kodu w niektórych sytuacjach, po prostu jest to jedna sytuacja, w której może być lepszy sposób, aby to zrobić, więc programista może śledzić zmiany w swoim źródle, nawet jeśli nie jest na to gotowe wpisane do głównego repozytorium.

Jest oczywiste, że programista, który sprawdza zakomentowany kod, powinien pracować w oddzielnej gałęzi, w razie potrzeby wprowadzając zmiany z gałęzi głównej.

To od systemu VCS zależy pomoc dewelopera w tym przepływie pracy (git to jeden doskonały system VCS, który bardzo dobrze z nim współpracuje).