Jak mogę ustawić refaktoryzację jako priorytet dla mojego zespołu?

Baza kodów, z którą codziennie pracuję, nie ma zautomatyzowanych testów, niespójnych nazw i mnóstwa komentarzy, takich jak „Dlaczego to jest tutaj?”, „Nie jestem pewien, czy jest to potrzebne” lub „Ta metoda nie jest odpowiednio nazwana”, a kod jest zaśmiecony „Listy zmian”, mimo że korzystamy z kontroli źródła. Wystarczy powiedzieć, że nasza baza kodów mogłaby użyć refaktoryzacji.

Zawsze mamy zadania naprawiania błędów lub dodawania nowych funkcji, więc nie trzeba poświęcać czasu na ulepszanie kodu, aby był on lepszy i bardziej modułowy, i nie wydaje się to mieć wysokiego priorytetu.

Jak mogę wykazać wartość refaktoryzacji, aby została dodana do naszych list zadań? Czy warto po prostu refaktoryzować, kiedy idę, prosząc o wybaczenie, a nie o pozwolenie?

„Lepiej prosić o wybaczenie niż pozwolenie” jest prawdą.

Po co się tym martwić? Po prostu refaktoryzuj najstraszniejsze części.

Wiesz już, jakie są najbardziej kosztowne błędy, prawda?

Jeśli tego nie zrobisz, krok 1 polega na pozytywnym i jednoznacznym zdefiniowaniu najbardziej kosztownego, złożonego, pozbawionego błędów i zainfekowanego błędami kodu problemu.

Zidentyfikuj liczbę zgłoszeń problemów, godziny debugowania i inne bardzo konkretne, bardzo wymierne koszty .

Następnie napraw coś na liście problemów związanych z wysokimi kosztami .

Kiedy musisz poprosić o wybaczenie, możesz wskazać na redukcję kosztów.

W przypadku braku świadomości refaktoryzacja wymaga testów jednostkowych w celu wykazania, że ​​zachowania przed i po są zgodne. Najlepiej byłoby, gdyby był to zautomatyzowany, zakodowany test, na przykład test jednostkowy.

Oznacza to wybranie jednej rzeczy. Napisz test jednostkowy. Napraw to jedno. Dokonałeś dwóch ulepszeń. (1) napisał test i (2) naprawił kod.

Powtarzać.

Postępuj zgodnie z zasadą harcerza: opuść kemping (kod) trochę lepiej niż go znalazłeś. Nigdy nie słyszałem o tym, żeby ktoś pisał o drobnych poprawkach kodu „podczas gdy tam byli”.

Przyjmę być może zbyt cyniczny punkt widzenia.

Refaktoryzacja jest tak trudną pigułką do przełknięcia. Otrzymujesz odpowiedzialność i winę, a owoce twojej pracy często trafiają do kogoś innego, kto opiera się na twoim czystym kodzie.

Powiedziałbym, że jeśli takie praktyki inżynierskie stały się kulturą w twojej firmie, być może będziesz musiał walczyć na wyższym poziomie. Tak naprawdę nie walczysz o refaktoryzację, walczysz o doskonałość inżynieryjną, a taka zmiana pojawia się dopiero w zarządzaniu, gdy uderza ją w twarz. W tym scenariuszu prawdopodobnie będą szukać na zewnątrz samochodu najlepszych praktyk, a wszystkie twoje wspaniałe pomysły i tak zostaną zebrane.

Rozważ dołączenie do innej firmy, w której poważnie podchodzą do praktyk inżynierskich.

Zauważam, że wiele plakatów tutaj wydaje się być przekonanych, że problem w zarządzaniu - podczas gdy pytanie nie wspomina o tym.

Chciałbym pójść dalej: moim zdaniem kiepska baza kodu prawie nigdy nie jest bezpośrednią winą zarządzania. Kierownictwo nie napisało tego kodu, tak zrobili programiści (w mojej firmie są wyjątki, w których niektórzy z naszych obecnych kierowników napisali początkową bazę kodu). Dlatego problem kultury leży po stronie programistów - jeśli chcą, aby kultura się zmieniła, sami będą musieli się zmienić.

Staram się przekazać tę realizację i zmianę nastawienia także „moim” programistom. Ilekroć pytają mnie „kiedy będziemy mieli czas na refaktoryzację?”, Jestem zaskoczony i odpowiadam „powinieneś już cały czas refaktoryzować!”. Uważam, że jedynym sposobem na utrzymanie bazy kodu w dobrej kondycji jest trzykrotność:

1. Zawsze dodawaj tylko zdrowy kod.
2. Zawsze naprawiaj niezbyt zdrowy kod, gdy tylko go zobaczysz.
3. Jeśli z powodów związanych z terminem nie możesz zrobić 1 lub 2, zawsze masz listę problemów „napraw natychmiast po terminie” i nie akceptuj żadnych usprawiedliwień, że nie przepracowałeś tej listy po terminie.

Niezmiennie następna uwaga od deweloperów brzmi „ale jak mamy na to czas - nie mamy teraz czasu?”. Jedyną poprawną odpowiedzią (ponownie IMHO) jest „nie masz czasu, aby tego NIE robić”. Jeśli nie utrzymasz bazy kodów w dobrej kondycji, zauważysz, że czas realizacji jest coraz dłuższy, harmonogramy stają się coraz bardziej nieprzewidywalne, błędy stają się bardziej nieprzyjemne, a wartość spada.

Największa zmiana nastawienia, którą musisz wprowadzić w zespole programistycznym, polega na tym, że „jakość” nie jest czymś, co robisz w określonym momencie („kiedy mamy czas na refaktoryzację”) - jest to coś, co musisz robić CAŁO.

Wreszcie historia ostrzeżenia. Jeśli zostanie naciśnięty, zaprzeczę, że to się kiedykolwiek wydarzyło. W firmie, w której pracowałem, istniała długoletnia aplikacja z dużą, starszą bazą kodów, która powstała ponad 10 lat temu. Wielu programistów, w tym ja, uważało, że ta starsza baza kodów była zła lub przynajmniej nieaktualna, a nie najnowocześniejsza. Lobbowaliśmy więc za dużym projektem refaktoryzacji i rozpoczęliśmy projekt przepisywania, po którym wierzyliśmy, że wszystko będzie lepiej.
Pracowaliśmy długo i ciężko, wdrażając prawie wszystko w nowy i nowoczesny sposób, wykorzystując nowe biblioteki, nowe funkcje językowe. Pod koniec dołożyliśmy ogromnych starań, aby zebrać wszystko w całość, aby umożliwić nową edycję długoletniej aplikacji z nową i ulepszoną bazą kodu.
Zgodnie z oczekiwaniami, nowe wydanie miało pewne problemy z ząbkami, z powodu nowych bibliotek, których jeszcze nie znaliśmy, oraz pewnych interakcji w naszym kodzie, których nie przewidzieliśmy. W końcu udało nam się jednak doprowadzić wersję do tego samego standardu, co nasze poprzednie wersje, i to na wyciągnięcie ręki. Odetchnęliśmy z ulgą po naszym „sukcesie”. Następnie podgrupa programistów wróciła do zarządzania, prosząc o nowy projekt refaktoryzacji, ponieważ nasz nowy kod nie był taką srebrną kulą, jakiej się spodziewali, i zobaczyli okazje do całkowitego przepisania niektórych rzeczy ...

Morał tej historii: często rzeczy nie są tak zepsute, jak się wydają, a „rozpoczęcie od nowa” zwykle oznacza, że ​​będziesz wymieniał znany zestaw problemów z co najmniej tak samo włochatym nieznanym zestawem problemów. Refaktoryzuj jedną część na raz!

Ktoś mi kiedyś powiedział, że kiedy idę na rozmowę kwalifikacyjną, nie powinienem zapominać, że przeprowadzam również wywiad z firmą. Czy to miejsce, w którym chcę pracować? Czy robią recenzje kodu? Czy mają zautomatyzowane testy integracyjne? Testy jednostkowe? Co myślą o programowaniu w parach? Osobiście znajdę inną pracę i tym razem nie zapomnę też zadać pytań.

Znajdź szczerze inną firmę. Takie ulepszenia w procesie rozwoju wymagają ogromnych skoków kulturowych, że zajmie to dużo czasu, zanim wszyscy znajdą się na tej samej stronie, a do tego czasu nie będziesz się tak przejmować.

Jeśli czujesz, że wciąż masz w sobie walkę i jeszcze się nie poddałeś, to wykonaj ostateczny atak. Postaraj się uzyskać jak najwięcej wsparcia od podobnie myślących członków zespołu, ujawnij swoje wyczerpanie przełożonym, którzy dbają o twoje samopoczucie, całkowicie obejdź i zdystansuj każdego, kto mógłby się sprzeciwić twoim przekonaniom, i spróbuj wcisnąć kilka godzin obowiązkowej refaktoryzacji w planowanie nowego projekty / funkcje.

Jeśli jesteś pasjonatem tego, co robisz i dbasz o swoją firmę, byłby to godny pochwały wysiłek po twojej stronie. Jeśli nie jest to doceniane, uszanuj siebie i wyskocz przed nim, zanim zmienisz się w pustego programistę.

Gdybym musiał wprowadzić jedną praktykę, aby poprawić sytuację w tego rodzaju kontekście, byłyby to recenzje kodu. Recenzje kodu są

• ogólnie intuicyjnie akceptowane przez programistów jako czynnik zapewniający lepszy kod, mniej błędów itp.
• współpracujący i demokratyczny
• nie jest to zbyt czasochłonne, jeśli odpowiednio je odtwarzasz
• dobre miejsce na refaktoryzację, jeśli nie masz na to czasu podczas „normalnego” rozwoju
• całkiem skuteczny koń trojański, który stopniowo wprowadza wszelkiego rodzaju najlepsze praktyki w zakresie projektowania kodu, testowania jednostkowego ...

Nie musisz systematycznie przeglądać kodu, tylko na początku, gdy popełniasz duże / złożone części kodu.

Oczywiście, jeśli uważasz, że potrzebujesz oficjalnego poparcia przed wprowadzeniem recenzji kodu, być może będziesz musiał najpierw przekonać swojego szefa, że ​​baza kodu prawdopodobnie się zawali, jeśli rzeczy pozostaną takie, jakie są.

Oto, co robię w takich sytuacjach (w ciągu 15 lat mojej kariery jako programisty prawie codziennie napotykałem taki kod)

1. Dawaj dobry przykład - upewniam się, że ponownie uwzględniam kod, którego dotykam. Bezwzględnie usuwam stary skomentowany kod i duże akapity komentarzy.
2. Proś o zmianę faktury za każdym razem, gdy poproszę o sprawdzenie zmiany kodu, bez której nie zatwierdzam recenzji kodu.
3. Powoli ludzie widzą zmianę, gdy kod staje się bardziej uproszczony, bardziej czytelny, a przez to mniej błędny. To wymaga czasu, ale powoli cały zespół docenia i przyjmuje praktykę.

Kierownictwo nigdy nie przeznacza czasu na ponowny faktoring kodu (nigdy nie ma wystarczających zasobów!), Więc robienie tego powoli i systematycznie jest właściwym podejściem.

Poproś kierownictwo o przeprowadzenie badań dotyczących „długu technicznego”. Odwołaj je również do „Teorii rozbicia okna”, oba te efekty mają bezpośredni wpływ na wydajność, jakość i morale.

„Czyste miejsce pracy to bezpieczne i produktywne miejsce pracy”, a każdy wkład w bałagan potęguje bałagan w sposób wykładniczy, a nie liniowy.

Jeśli sytuacja nie zostanie rozwiązana, w końcu przekroczysz punkt bez powrotu, w którym stanie się to ekonomicznie niewykonalne, postępując z nią stopniowo, zanim to nastąpi, korzyści odbędą się, dając ci więcej paliwa, aby poradzić sobie z problemem w trakcie podróży.

Wygląda na to, że twoje problemy są bardziej ogólne.
Problem refaktoryzacji jest zarówno objawem, jak i potencjalną ulgą od części problemu.

Kierownik ds. Oprogramowania i zespół przydzielają czas zespołowi

Z mojego doświadczenia wynika, że ​​możesz napotykać problem, który nazywam „każdy jest menedżerem oprogramowania”. Menedżerowie produktu, kierownicy projektów, a czasem inżynierowie i testerzy systemów mogą być znani z próby zarządzania mikro programistami, którzy prawdopodobnie mają już doświadczonego menedżera oprogramowania. Możesz nawet mieć kilku członków swojego zespołu, którzy uważają, że ich rolą jest zarządzanie.

Jeśli jesteś menedżerem oprogramowania, dokonaj zleceń refaktoryzacji, które chcesz, lub jeszcze lepiej, poproś zespół o zaproponowanie refaktoryzacji do zatwierdzenia. Aby nie zarządzać mikromaningiem, możesz mieć wytyczne dotyczące wieku / autora / rozmiaru / kontekstu kodu, który ma być refaktoryzowany, który można dowolnie refaktoryzować vs. wymagać zgody. Jeśli członek twojego zespołu chce masowo zreformować cztery duże klasy skomplikowanego starego kodu, którego nie napisał, a które nie są częścią jego funkcji, jego dwutygodniowe przekierowanie jest twoim problemem, więc potrzebujesz szansy, aby powiedzieć „nie”.

Możesz się przekraść, ale myślę, że lepiej jest po prostu ostrożnie budować swoje szacunki z czasem na analizę, projektowanie, kodowanie, wiele form testowania (przynajmniej jednostki i integracji), refaktoryzację i ryzyko, jak sądzono historycznie i przez brak doświadczenie lub przejrzystość związane z zadaniem. Jeśli byłeś zbyt otwarty na temat pracy swojego zespołu (lub masz członków w swoim zespole, którzy są), rozsądne może być wąskie kanały komunikacji, aby przechodzili przez ciebie i omawiali zasoby i wyniki, a nie metody.

Wczesne wybory projektu Utwórz błędne koło do refaktoryzacji

Konserwacja oprogramowania jest trudna. Podwójnie trudno jest, jeśli inni w organizacji dokonują wyborów na własny koszt. To źle, ale nie jest nowe. Zajmuje się tym Barry Boehm, jeden z naszych wielkich twórców oprogramowania, który przedstawia model zarządzania, który określa jako Teoria W.

http://csse.usc.edu/csse/TECHRPTS/1989/usccse89-500/usccse89-500.pdf

Często programiści są wkurzeni, aby produkować zgodnie z podejściem do zarządzania Theory-X, które mówi, że pracownicy są w zasadzie leniwi i nie będą działać, chyba że zostaną zmuszeni do poddania się. Boehm podsumowuje i kontrastuje swój proponowany model w następujący sposób:

„Zamiast charakteryzować menedżera jako autokratę (Teoria X), trenera (Teoria Y) lub facylitatora (Teoria Z), Teoria W charakteryzuje podstawową rolę menedżera jako negocjatora między jego różnymi okręgami wyborczymi i pakietem rozwiązań projektowych z warunkami wygranej dla wszystkich stron. Poza tym menedżer jest także wyznacznikiem celów, monitorem postępów w osiąganiu celów i aktywistą w poszukiwaniu codziennych konfliktów między projektami typu wygrana-przegrana lub przegrana-przegrana, konfrontując je, i zmieniając je w sytuacje korzystne dla obu stron ”.

Szybka i brudna często jest po prostu brudna

Boehm wskazuje dalej, dlaczego programiści z zespołu konserwacyjnego są tak nieszczęśliwi.

„Zbudowanie szybkiego i niechlujnego produktu może być tanią, krótkoterminową„ wygraną ”dla twórcy oprogramowania i klienta, ale będzie to„ strata ”dla użytkownika i opiekuna”. Należy pamiętać, że w modelu Boehm klient jest raczej administratorem umowy niż użytkownikiem końcowym. W większości firm myśl o menedżerze produktu jako o surogacie klienta, a może o osobie, która kupuje produkt na liście funkcji.

Moim rozwiązaniem byłoby, aby nie wypuszczać pierwotnego zespołu programistów (lub przynajmniej oryginalnego leadu), dopóki kod nie zostanie zrefaktoryzowany, aby przynajmniej spełniał standardy kodowania.

Uważam, że dla klienta rozsądne jest uznanie menedżera produktu za surogat klienta, a grupę osób nagradzanych za dostarczenie czegoś szybkiego i brudnego można z pewnością poszerzyć, więc istnieje duży wybór, aby robić rzeczy w niewłaściwy sposób.

Refaktoryzacja nie podlega negocjacji

Nie wycofuj się z roli menedżera oprogramowania. Powinieneś mieć uprawnienia i dyskrecję, aby wykorzystać czas swojego zespołu na doskonalenie procesów i produktów. W tej roli może być konieczne negocjowanie wyborów, aby Twój zespół był bardziej profesjonalny. Jednak jeśli chodzi o proces, nie negocjuj z marketingiem, ponieważ z mojego doświadczenia jest to przegrana gra. Negocjuj z kierownictwem inżynieryjnym. To pokazuje, że masz wizję. Budowanie profesjonalnego zespołu oprogramowania jest przedłużeniem ich roli i jest o wiele bardziej prawdopodobne, że będzie postrzegane jako korzystne dla wszystkich.

Zawsze możesz po prostu poczekać. W końcu zespół spóźni się z wystarczającymi terminami i wyprodukuje wystarczająco dużo błędów, aby zarząd podniósł ręce i powiedział, że na Boga coś lepiej się zmieniło!

Dobra, to ryzykowna propozycja. Ale tak naprawdę wydarzyło się w naszym sklepie kilka lat temu (część trudności polegała na komunikowaniu się z zarządem na temat terminów, ale to inna historia) i jest to główny powód, dla którego mamy teraz dziesiątki tysięcy automatycznych testów, współdzielenie kodu, wolność refaktoryzacji, gotowość do usuwania martwego kodu i wydania najwyższej jakości, jakie kiedykolwiek mieliśmy.

Być może najbardziej zaskakujące jest to, że nikt nie stracił pracy w tym procesie - coś, co zawdzięczam naszemu szefowi, który przyszedł do nas, i konsultantowi, który argumentował za refaktoryzacją i ciągłą integracją w naszym imieniu. Zawsze brzmi to bardziej przekonująco, gdy mówi to ktoś z zewnątrz.

Myślę, że odpowiedź na pytanie, jak znaleźć czas, zależy od tego, dlaczego chcesz zmienić kod.

Jeśli to działa, nie ma potrzeby specjalnego refaktoryzacji i możesz to zrobić po dotknięciu tej części kodu. Dlatego nie potrzebujesz na to specjalnego czasu.

Jeśli to spowolni rozwój twojego zespołu, musisz porozmawiać o tym z liderem zespołu i stworzyć specjalne zadanie do refaktoryzacji i że będziesz miał czas.

To samo dotyczy szybkości działania i innych przypadków, jeśli refaktor może coś ulepszyć, a nie tylko „dobrze wygląda kod” lub twoją opinię o tym, jak powinien wyglądać kod i zapewnić rzeczywistą korzyść, stworzyć zadanie lub porozmawiać z osobą odpowiedzialną za to.

Śmiałem się trochę ze sposobu, w jaki opisałeś rzeczy, ponieważ to brzmi dość podobnie do bazy kodu, nad którą pracuję, więc myślę, że nasze sytuacje są bardzo podobne. Na szczęście w mojej sytuacji mam wybiegającego w przyszłość menedżera, który zdecydował, że najlepszym sposobem na ulepszenie bazy kodu jest modularyzacja przy użyciu nowoczesnych ram programistycznych, a nie tylko refaktoryzacja całej bazy kodu. W ten sposób kłopotliwe miejsca głównej aplikacji można przepisać jako osobne moduły, a następnie zintegrować z główną aplikacją (ale nadal być zasadniczo niezależnym). Może to być podejście, które chcesz wprowadzić, ponieważ nie wymagałoby to refaktoryzacji całej (prawdopodobnie dużej?) Bazy kodu, z którą pracujesz.

Oczywiście, mogę trochę odejść od tego, co mówisz, ponieważ być może twoja baza kodu nie jest tak zła, jak ta, z którą pracuję, w takim przypadku powiedziałbym, dlaczego nie robić małych optymalizacji podczas pracy? Twórcy w moim zespole nie mają problemu z usuwaniem głupich lub nieaktualnych komentarzy i rzeczy tego rodzaju i nie sądzę, że powinno to wymagać wkładu ze strony kierownictwa, ponieważ zwykle programiści mają pewne uprawnienia do optymalizacji rzeczy w razie potrzeby.

Jeśli podstawa kodu jest naprawdę delikatna, musisz być ostrożny i może to być powodem, dla którego mogą nie chcieć przeprowadzać poważnego refaktoryzacji, ponieważ może to skończyć się projektem trwającym miesiąc i prawdopodobnie wymagałoby rozgałęzienia projektu i umieszczenia na nim deweloperów projekt i odejmowanie od innych zadań programistycznych, takich jak natychmiastowe poprawki błędów, które mogą powodować utratę klientów itp

Biorąc wszystko pod uwagę, o ile inni mówią, że należy rzucić palenie itp., Myślę, że to zależy od tego, jak kierownictwo postrzega rzeczy, jeśli rozumieją sytuację i zdają sobie sprawę, dlaczego niektóre rzeczy mogą trwać dłużej niż powinny, to może być dobrze, ponieważ jeśli chodzi o środowisko pracy, ale jeśli ciągle docierają do ciebie z powodu zaległości w pracy, może to z czasem stać się szkodliwe. Mam szczęście, że mam zarząd, który w zasadzie zdaje sobie sprawę, że aplikacja to bzdura, ale ma wielu klientów i przynosi pieniądze, więc nadal jest cenna i warta naprawiania błędów, nawet jeśli tylko na krótko .

Twoim głównym problemem jest to, że kody nie są wystarczająco widoczne.

Suggets używam narzędzia do ciągłej integracji, takiego jak Jenkins , oraz zintegrowanego z nim narzędzia do analizy kodu statycznego, które mierzy złożoność cykliczną, standardy nazewnictwa, długość kodu itp.

Gdy programista dokonuje zmiany, Jenkins przeprowadza testy jednostek, uruchamia na nim narzędzie do analizy kodu statycznego i generuje raport internetowy, który każdy może zobaczyć, ze statusem koloru przypominającym sygnalizację świetlną.

Gdy jakość kodu jest widoczna dla wszystkich (zwłaszcza lidera zespołu i szefa), a kontrola wersji i testy jednostkowe są dostępne, aby mieć twoje plecy ... ludzie zachęcani są do refaktoryzacji.

Kod przechodził powoli przez wiele małych zmian. Trzeba będzie również to naprawić.

Możesz to zrobić na bieżąco - przede wszystkim - zwiększyć wszystkie szacunki o 10%, aby umożliwić ulepszenie kodu i długoterminową konserwację. Jeśli ktoś narzeka, zapytaj go, czy lepiej sprawdzać olej w silniku samochodowym co tydzień, czy też czekać, aż silnik całkowicie się zablokuje.

Spotkaj się i ustal spójne standardy kodowania.

Przedstaw podstawowe zasady, z których będziesz korzystać podczas pracy:

Ilekroć nowy kod jest wprowadzany do klasy, należy napisać automatyczne testy, aby udowodnić, że klasa działa (nie tylko nowy kod).

Ilekroć błąd zostanie naprawiony, należy napisać automatyczne testy, aby udowodnić, że klasa działa (nie tylko poprawiony kod).

Za każdym razem, gdy programista modyfikuje plik, musi naprawić wszystkie ostrzeżenia kompilatora w tym pliku i zaktualizować kod, aby spełniał nowe standardy kodowania.

Po pewnym czasie najczęściej używany kod będzie aktualny i objęty automatycznymi testami. Starszy kod zostanie zaktualizowany po zmianie, jeśli nigdy nie zostanie zmieniony, nie musisz się o to martwić.

Ważną rzeczą jest wbudowanie tych nawyków w standardowe zadania kodowania, aby żadne z nich nie poświęcało zbyt wiele czasu na „prawdziwą” pracę, ale wszystkie zapewniają rzeczywiste korzyści. Nie próbuj tworzyć projektu z refaktoryzacji starego kodu, jest to przerażający, nudny, skrzywdzony ból, który będzie wyglądał jak marnowanie czasu na non-technies!

Sposobem na zdobycie potrzebnych zasobów (czasu) jest skupienie się na dostosowaniu zdolności i pożądania. Twój szef kieruje się celami (zazwyczaj zyski lub czasy dostawy nowych funkcji) i widzi refaktoryzację jako inżynierów marnujących czas i pochłaniających te cele. Musisz znaleźć sposób, aby przekonać go, że cele zostaną osiągnięte i przekroczone, jeśli spędzisz czas na refaktoryzacji.

Pierwszym krokiem jest więc sprawdzenie, jaki ból odczuwa Twój szef. Zidentyfikuj jego największe problemy. Następnie dowiedz się, jak to zrobić, i jak rozwiązać jego problemy, i przedstaw solidne uzasadnienie biznesowe. Skorzystaj z systemów śledzenia defektów i planowania projektu (przekroczenia czasu), aby dostarczyć dowodów na to, gdzie leżą problemy. Potrzebujesz faktów, a nie uczuć. Bez metryk (liczba błędów / moduł, koszt ich naprawy) refaktoryzacja jest po prostu programistą, który gra na czyimś kosztem. Twój szef da ci potrzebne zasoby tylko wtedy, gdy będziesz w stanie udowodnić, że jest to uzasadnione.

Kod bzdury jest często zbyt drogi do naprawienia. Bez zautomatyzowanych testów regresji koszt testowania zrestrukturyzowanego kodu jest niezwykle wysoki.

Przez większość czasu widziałem zły kod, który naprawdę wymagałby refaktoryzacji, było wiele nieudokumentowanych funkcji i złożoności wymagań, których nie można zrozumieć od samego początku. Nie jest to niewielkie przedsięwzięcie, a moje doświadczenie jest o rząd wielkości trudniejsze do oszacowania kosztu pracy refaktoryzacyjnej niż dodanie nowej funkcji.

Powstrzymałbym się przed zrobieniem tego za plecami bossów (jeśli nie został złamany, a ty go złamałeś, jak to wygląda) - napraw kod, który i tak wymaga zmiany, ale jeśli nie jest zepsuty, nie rób tego napraw to.

O dziwo nikt nie wspomina o tym:

Aby wszystko stało się priorytetem, ułatw je: Uzyskaj dobre narzędzie do refaktoryzacji.

Istnieją doskonałe narzędzia do refaktoryzacji (przynajmniej dla .NET afaik). Aha, i nie zapomnij wcześniej napisać testów jednostkowych (jak już zauważyli inni).

Powodzenia!