Czy dobrze jest zaplanować regularny czas czyszczenia kodu? [Zamknięte]

Zarządzam małym zespołem programistów. Co jakiś czas decydujemy, że spędzimy dzień lub dwa, aby wyczyścić nasz kod.

Czy dobrym pomysłem byłoby zaplanowanie regularnego czasu, powiedzmy 1 tydzień co 2 miesiące, na samo oczyszczenie naszej bazy kodów?

Nie.

Napraw to podczas pracy:

• Jeśli zaczekasz na refaktoryzację fragmentu, nad którym pracujesz, wiele o nim zapomnisz i będziesz musiał poświęcić czas na ponowne zapoznanie się z nim.
• Nie uzyskasz kodu „pozłacania”, który nigdy nie będzie używany, ponieważ zmieniły się wymagania

Moja osobista opinia: jest absolutnie wymagana w przypadku 90% projektów.

Zwłaszcza w przypadku projektów, które są silnie napędzane przez sprzedaż, zwykle istnieje duży nacisk na włączenie nowych funkcji w każdym wydaniu, a nieuchronnie kończy się konieczność kompromisowania swoich lepszych instynktów i wprowadzenia kilku kludges / hacków tu i tam.

W końcu narosłeś wystarczający „dług techniczny” przez te małe kompromisy, że w końcu spędzasz sporo czasu na rozwiązywaniu problemów w bazie kodu i nie jesteś w stanie w pełni wykorzystać swojego potencjału.

Zwykle w ten sposób generowane są dwa rodzaje problemów:

• Małe, które można łatwo naprawić, ale mogą mieć charakter systemowy, np. Nieprawidłowo nazwane parametry, niepełna obsługa błędów itp. Zazwyczaj będą miały niewielki wpływ poza blok kodu, w którym się pojawiają. Najlepszym sposobem radzenia sobie z nimi jest przegląd kodu i sprawdzanie kodu podczas pisania / modyfikacji. Jak powiedzieli inni, nie ma potrzeby odkładania specjalnego cyklu refaktora, aby naprawić te błędy.
• Duże, które mogły wyniknąć z niepełnych specyfikacji lub złych decyzji projektowych na wczesnym etapie, lub dwóch programistów / zespołów tworzących dwa różne rozwiązania tego samego problemu. Są one na ogół znacznie trudniejsze do naprawienia i wymagają wspólnego wysiłku w celu naprawy. W rezultacie są zwykle odraczane, aż staną się wieczną uciążliwością. Tego rodzaju problemy wymagają poświęconego czasu na naprawę.

Generalnie staram się rezerwować czas na czysty cykl refaktoryzacji / naprawy błędów co 3 do 4 cykli. Zawsze proszę moich programistów, aby powiedzieli mi, kiedy czują się sfrustrowani bazą kodu. Nie każdy programista musi pracować nad czyszczeniem - zwykle (choć nie zawsze) można nieco rozłożyć zespoły, więc tylko jeden zespół pracuje nad czyszczeniem w danym momencie.

Mam moich programistów, którzy uporządkowali swój kod przed zalogowaniem (Subversion) lub połączeniem z główną gałęzią programistyczną (Git).

Mam je wykonać następujące czynności:

• Usuń niepotrzebne komentarze
• Upewnij się, że ich metody, argumenty i zmienne są odpowiednio nazwane
• Upewnij się, że w ich klasach jest struktura, a przedmioty są odpowiednio zamknięte
• Refaktoryzacja w celu poprawy czytelności i zmniejszenia wszelkich zapachów kodu

W przypadku większych projektów kod jest formalnie sprawdzany przed połączeniem z gałęzi programistycznej do gałęzi głównej.

Myślę, że „poświęcanie czasu” będzie oznaczało, że jest to coś, co może zostać odroczone lub odłożone ze względu na nakład pracy. Dzięki temu, że programiści robią to podczas pojedynczego zgłoszenia (co jest równoznaczne z żądaniem zmiany / problemem w JIRA), jest znacznie łatwiejsze do zarządzania.

Moim zdaniem nie. Jeśli poświęcisz zbyt dużo czasu między napotkaniem długu technologicznego a jego naprawieniem, tracisz kontekst, na czym polega problem. Naprawienie zajmuje więcej czasu i jest coraz gorzej. Co najważniejsze, ludzie wychodzą z rozbitych okien, ponieważ nie jest to „tydzień sprzątania”.

Osobiście negocjuję techniczne spłatę długów w każdym sprincie, jeśli wiem, że wcześniej je utworzyliśmy. Utrzymuje dług w świeżości w ludzkich umysłach. Ogranicza ilość kodu przy użyciu kodu problemu, dzięki czemu refaktoryzacja jest łatwiejsza. Zapobiega gromadzeniu się długu technicznego. Pomaga to deweloperom po prostu spakować coś razem, ponieważ po prostu sprawię, że zrobią to zaraz podczas sprintu (więc równie dobrze mogę to zrobić właściwie).

Powiedziałbym zdecydowanie tak, z zastrzeżeniem: należy to robić często, najlepiej raz w tygodniu. Uważam, że zaplanowana regularna kontrola kodu w połączeniu z faktycznym działaniem na elementy wychodzące z recenzji kodu bardzo szybko się zwraca. Zobacz odpowiedź pswg

1 tydzień co 2 miesiące zdecydowanie nie wystarcza. Odnosi się to do większości innych odpowiedzi, które odpowiedziały „Nie” na twoje pytanie. Istotą większości tych odpowiedzi jest to, że jeśli będziesz czekać zbyt długo, nie będziesz już w kontakcie z kodem i zwykle zajmuje dużo więcej czasu na naprawę / oczyszczenie / refaktoryzację.

Nie jest jasne, czy miałeś na myśli dodatkowe ćwiczenie czyszczenia kodu od czasu do czasu. W tym sensie tak. Niezależnie od tego, jakie praktyki stosujemy, zawsze dochodzi do degradacji.

Nie powinieneś używać tego jako usprawiedliwienia, aby nie postępować właściwie [stosując zasady SOLID, odpowiednie testy jednostkowe, inspekcje itp.].

Myślę, że obecnie dwie popularne odpowiedzi „Nie” „Tak” to dwa aspekty tej samej prawdy. Pamiętaj, że OP mówi o grupie, którą zarządza, a nie tylko o sobie jako jednostce. Nie możemy zakładać, że wszyscy programiści w grupie są wystarczająco zdyscyplinowani, aby pisać czysty, czytelny kod; jest też kwestia presji zewnętrznej i metodologii zwinnych. Ponadto, nawet przy najlepszych staraniach ludzi, ich różnice w stylu będą oznaczać, że mogą pisać kod, który byłby uważany za czysty, gdy byłby oddzielony, ale nieczysty, gdy byłby rozpatrywany razem z innymi ludźmi (nie wspominając o skrzypiących interfejsach).

Z drugiej strony, „napraw to podczas pracy” jest moim zdaniem ideałem, do którego należy dążyć. Możesz sprawić, że Twój kod wyjdzie jeszcze bardziej „naprawiony” przez

• ostrożny CRing
• pisanie testów jednostkowych wraz z samym kodem
• przyjmowanie wytycznych dotyczących kodowania
• przy użyciu automatycznych formatatorów i włókien (ale YMMV)
• itp.

Teraz, jeśli zespół PO przyjmie powyższe i jeśli zachęci swoich podwładnych - np. Podczas przeglądów kodu i podczas okresowych sesji czyszczenia kodu - do spróbowania z góry przewidzieć pułapki i uniknąć brzydoty, z czasem, mam nadzieję, będzie potrzebował mniej czas czyszczenia. (A potem mogliby poświęcić ten czas na dokumentację, głębsze refaktoryzacje i dzielenie się wiedzą na temat tego, co napisali i skonsolidowali.)

Myślę, że planowanie regularnego czasu jest bardzo dobre, niezależnie od tego, czy jest to zadanie w zwykłym projekcie w stylu wodospadu, czy historie w zwinnym. Ustalenie czasu może nie być tak cenne, jak samo zaplanowanie go. Umożliwia to wykonanie tego w ramach harmonogramu w porównaniu z anulowaniem dnia czyszczenia, ponieważ opóźniasz się w realizacji projektu.

Po zarządzeniu projektem, który miał olbrzymią ilość długów kodu, regularna praca z nimi była kluczem do sprawnego działania. Niektóre z naszych rzeczy były duże, niektóre były małe.

Po kilku miesiącach takiej pracy kierownictwo naszego zespołu operacyjnego powiedziało mi, jak gładko wszystko działa.

Każda pozycja może nie wyglądać na wiele, ale podobnie jak wszystkie długi, reklamuje się.

Idealna odpowiedź brzmi „nie”, ponieważ podejmujesz kroki niezbędne, aby uniknąć konieczności uczynienia tego koniecznym (posprzątaj w miarę postępów z kilku już wymienionych powodów).

To może być cel na końcu, ale możesz mieć zespół, który jest daleki od wprowadzenia tego w życie.

Menedżerowie muszą wziąć na siebie odpowiedzialność Nie zawsze jest to wina dewelopera. Menedżerowie mogą powiedzieć jedno, ale zaczynają naciskać na ukończenie projektów i przedstawiać sugestie promujące złe praktyki. Mogą dosłownie powiedzieć „później to posprzątamy” lub jeśli to zadziała, to wystarczy.

Być może trzeba zacząć od poświęcenia określonego czasu, aby pokazać, że jest to ważne. Gdy wiesz, że Twój zespół jest w stanie wyczyścić swój kod (a nie dany), możesz spróbować włączyć go częściej.

W końcu nie powinieneś ustawiać czasu.

Osobiście mam problem z rozwiązaniem nowego problemu i doprowadzeniem go do działania, jednocześnie starając się utrzymać porządek. Robię się coraz lepszy, ale często robię sobie celową przerwę i sprzątam. Dla mnie to inny sposób myślenia. W końcu solidne praktyki stają się nawykiem.

Nie, powinieneś to zrobić podczas kodowania. Nazywa się to refaktoryzacją, jeśli używasz TDD. Problem, gdy czekasz miesiąc lub dwa, aby naprawić i wyczyścić kod, polega na tym, że możesz zmienić zachowanie kodu, ponieważ nie pamiętasz każdego fragmentu kodu.

Sugeruję refaktoryzację, która polega na kodowaniu najpierw kodu niezbędnego do działania, a gdy tylko zadziała, przeprojektuj go, zoptymalizuj i upiększ.