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

42

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?

— użytkownik84667
źródło

9

Wolałbym najpierw zacząć rejestrować wszystkie rzeczy wymagające czyszczenia w narzędziu do śledzenia problemów . Analiza problemów zarejestrowanych w module śledzącym może dać jeden lepszy (znacznie lepszy) pomysł na to, jakie byłoby najbardziej odpowiednie podejście do konkretnego projektu

— gnat

4

Lepiej byłoby zaplanować regularny czas na przegląd kodu

— l46kok

1

Co masz na myśli mówiąc „posprzątaj”? Czy poprawia kod, czy obsługuje wszystkie tagi FIXME i TODO, czy też osiąga większą wydajność dzięki szybko napisanemu kodowi? Albo coś innego? Każde z nich można zaklasyfikować jako sprzątanie, ale do każdego z nich dołączam inne priorytety.

— Paul

Kolejny „zamknięty jako zbyt popularny”, co, chłopaki?

— MGOwen

100

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

— MGOwen
źródło

2

Moje pieniądze na tę odpowiedź ..

— Soner Gönül

2

+1 za doskonałą odpowiedź. Nie skończysz na „złotym” kodzie, który nigdy nie zostanie użyty, ponieważ zmieniły się wymagania

— Md Mahbubur Rahman,

8

W przypadku idealnego projektu z doskonałym zarządzaniem i zespołem jednakowo świetnych programistów odpowiedź ta byłaby ważna. Niestety, nigdy nie widziałem ani nie słyszałem o takim projekcie przez dziesięć lat w branży.

— Ben

3

Spróbuj to zrobić, ale jeśli nie możesz (a stanie się to z powodu presji czasu lub dlatego, że po prostu nie wiesz, jak to zrobić dobrze), utwórz bilet w systemie biletów. W ten sposób możesz powrócić do niego, gdy problem jest wciąż świeży w umyśle, i to nie tylko wtedy, gdy w końcu zaczyna powodować problemy.

— Sarien

1

Myślę, że to dobra rada, ale nie odnosi się do zadanego pytania. Haivng zarządzał zespołem z przerażającą bazą kodów (był przerażający, zanim tam dotarłem). To był bardzo dobrze spędzony czas, aby zająć się refaktoryzacją i czyszczeniem określonych funkcji. Nazwaliśmy je projektami infrastrukturalnymi i pracowaliśmy nad każdym sprintem, jaki mogliśmy. Często były to przedmioty, które nie były częścią innej zmiany, ale były rzeczami, które zespół zidentyfikował jako obszary problemowe. Przeprowadzaliśmy kwartalne retrospekcje i regularnie aktualizowaliśmy tę listę.

— Bill Leeper

21

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.

— pswg
źródło

1

Nie rozumiem, że zwiększona liczba dużych pchnięć jest zwinnym problemem.

— JeffO

2

@JeffO Nie, to nie jest zwinny problem. To problem z zarządzaniem. Z tego, co widziałem, firmy, na które duży wpływ ma sprzedaż, mają skłonność do agresywnych cykli wydawania i dużych zestawów funkcji. Zwinne strategie zazwyczaj przemawiają do tych firm (niezależnie od tego, czy naprawdę stosują się do strategii, czy nie). Chociaż lubię sprawny rozwój, moje doświadczenie pokazało, że gdy firma nazywa się „zwinnym”, zwykle oznacza to, że mogę spodziewać się sporego zadłużenia technicznego w bazie kodu.

— pswg,

Myślę, że jeśli w ogóle nie mają metodologii, mogą się nazywać, jak chcą. Ponieważ zwinne, to aktualne modne hasło, jest najbardziej atrakcyjne. Minęło trochę czasu, odkąd byłem przy projekcie wodospadu; była to taka katastrofa na tak wiele innych sposobów, że nigdy nie używam jej jako argumentu przeciwko metodologii.

— JeffO

W każdym projekcie, zwinnym lub nie, refaktoryzacja i czyszczenie kodu jest czymś, co robisz na bieżąco, aby stale utrzymywać dług techniczny do minimum. Jeśli nie uwzględnisz tego w swoich szacunkach, będziesz musiał zacząć to robić. Nie możesz pozwolić, aby dług techniczny narastał, dopóki nie będziesz musiał zatrzymać wszystkiego, aby go naprawić. Zamiast tego postępuj zgodnie z zasadą zwiadowczą: „Zawsze zostawiaj kod czystszy, niż go znalazłeś”.

— Christoffer Hammarström

Z mojego doświadczenia wynika, że niedoświadczone zespoły zaczynające od scrum, bez przestrzegania dobrych zasad kodowania (takich jak XP), mogą czasami zbytnio skupiać się na funkcjonalności (opowiadaniach). Zamiast tego powinni powiedzieć, że historia nie jest skończona, dopóki kod nie będzie wystarczająco „dobry”, ale nie wszyscy mają wystarczająco dużo kręgosłupa, aby zrobić to w zbliżającym się terminie. A dzięki Agile masz więcej terminów w krótszym czasie, więc kojarzę to również z metodami Agile, podczas gdy jestem całkowicie świadomy, że nie są one przyczyną.

— markijbema

11

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.

— Sam
źródło

Z ciekawości: dlaczego używasz dwóch różnych VCS?

— Eekhoorn

2

Była / jest faza migracyjna. Przeprowadziliśmy migrację większości repozytoriów SVN, o których wspomniałem w pewnym kontekście.

— Sam

To jest to, co robie. Wyczyść kod przed meldowaniem i prześlij go ponownie, jeśli wrócę do kodu w celu poprawy funkcjonalności.

— Barfieldmv

1

Nie rozwiąże to tych dokuczliwych problemów, które czają się w obszarach, które mogą nie być częścią żądania funkcji od zespołu produktu.

— Bill Leeper

9

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).

— Telastyn
źródło

Twoje drugie zdanie jest sprzeczne z pierwszym. Powiedziałeś „nie”, a potem powiedziałeś, że robisz tego rodzaju rzeczy podczas każdego sprintu. W sposób zaplanowany, aby to zrobić.

— Bill Leeper

2

@BillLeeper - enh. Kiedy słyszę „regularny czas”, oznacza to, że jest jakiś regularny odstęp czasu na wykonanie prac porządkowych. IMO, to niepoprawne - cały czas jest odpowiedni czas na prace porządkowe.

— Telastyn

1

Dobrze, zgadzam się, że regularny czas nie działa dobrze. Zbyt często priorytety powodują anulowanie itp.

— Bill Leeper

4

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ę.

— Mauritz Hansen
źródło

Robimy za to „wtorek długu technicznego”. Jego połowa drogi rzuciła izraelski tydzień pracy i pozwala nam cofnąć się o krok do rozwiązania problemów

— Zachary K

1

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.].

— Jayan
źródło

1

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.)

— einpoklum - przywróć Monikę
źródło

1

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ę.

— Bill Leeper
źródło

1

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.

— JeffO
źródło

-1

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.

— Ricardo Mogg
źródło

Nazywa się to refaktoryzacją, niezależnie od tego, czy korzystasz z TDD, czy nie. To pytanie nie ma nic wspólnego z TDD ...

— Ben Lee