Kiedy przepisać bazę kodu od podstaw

Książka fakty i błędy Inżynierii Oprogramowania stwierdza ten fakt: "Modyfikacja ponownie użytego kodu jest szczególnie podatna na błędy. Jeśli więcej niż 20 do 25 procent komponentu ma zostać poprawione, bardziej wydajne i skuteczne jest przepisanie go od zera." Liczby pochodzą z niektórych badań statystycznych przeprowadzonych na ten temat. Myślę, że liczby mogą się różnić ze względu na jakość bazy kodu, więc w Twoim przypadku bardziej wydajne i skuteczne wydaje się przepisanie go z scratch, biorąc pod uwagę to stwierdzenie.

Artykuł Joela naprawdę mówi wszystko.

W zasadzie nigdy.

Jak zaznacza Joel: po prostu zbyt wiele stracisz robiąc to od zera. To pewnie potrwa znacznie dłużej niż myślisz i jaki jest efekt końcowy? Coś, co zasadniczo robi to samo. Więc jaki jest biznes case za zrobienie tego?

To ważna uwaga: napisanie czegoś od zera kosztuje dużo pieniędzy. Jak odzyskasz te pieniądze? Wielu programistów ignoruje ten punkt po prostu dlatego, że nie podoba mi się kod. czasem z uzasadnieniem, czasem nie.

Miałem taką aplikację, a przepisywanie było bardzo satysfakcjonujące. Należy jednak spróbować aviod pułapki "poprawy".

Kiedy wszystko przepisujesz, bardzo kuszące jest dodawanie nowych funkcji i naprawianie niektórych długotrwałych problemów, których nie miałeś odwagi dotknąć. Może to prowadzić do pełzania funkcji, a także znacznie wydłużyć czas potrzebny na przepisanie.

Upewnij się, że zdecydujesz, co dokładnie zostanie zmienione, a co tylko zostanie przepisane- z góry .

Trochę się z tym artykułem nie zgadzam. W większości przypadków Joel jest poprawny, ale istnieją kontra-przykłady, które wskazują, że czasami (nawet jeśli rzadko) przepisanie jest dobrym pomysłem. Np.,

• Windows NT (oderwał się od starej bazy kodu DOS. Na tej podstawie został zbudowany Win2k, WinXP i nadchodzące Win7. Tak, Vista też. Ostatnia wersja systemu Windows na starej bazie była niesławnym WinME)
• Mac OS X (przebudował swój flagowy produkt na FreeBSD)
• wiele przypadków, w których konkurent wypiera de facto standard. (np. Excel vs. Lotus 123)

Uważam, że argument Joela opiera się głównie na dość dobrze napisanym kodzie w istniejącej wersji, który można poprawić z perspektywy czasu. Oczywiście, jeśli kod, który odziedziczyłeś jest naprawdę taki zły, wciśnij do przepisania -- tam są straszne rzeczy. Jeśli jest to w ogóle tolerowalne i działa w miarę dobrze, Faza w nowych rzeczy w wolniejszym tempie.

Byłem częścią małego dedykowanego zespołu, który przepisał Kod od podstaw, w tym zasady biznesowe inżynierii odwrotnej wcześniejszego kodu. Oryginalną aplikacją był web service napisany w C++ (z regularnymi awariami i poważnymi wyciekami pamięci) i ASP.Net 1.0 aplikacji webowej, a jej zamiennikiem był serwis internetowy oparty na C# 2.0 asmx oraz ASP.Net 2.0 aplikacja internetowa z Ajaxem. To powiedziało niektóre rzeczy, które zespół zrobił i wyjaśnił kierownictwu

1. wspieraliśmy istniejąca baza kodu w produkcji do czasu, gdy nowy kod był gotowy.
2. Zarząd zgodził się, że rewrite (pierwsze wydanie) nie wprowadzi żadnych nowych funkcji, a jedynie zaimplementuje istniejące funkcje. Dodaliśmy tylko 1-2 nowe funkcje na końcu.
3. mały zespół składał się z bardzo doświadczonych programistów o doskonałych umiejętnościach rozumienia i współpracy.
[[3]] trudniej było zdobyć talent C++ w organizacji, A C# było postrzegane jako lepsza alternatywa dla przyszłości konserwacja.
4. zgodziliśmy się na agresywne ramy czasowe, ale jednocześnie byliśmy pewni siebie i wysoce zmotywowani do pracy w C# 2.0, ASP.Net 2.0 itd.
[3]}mieliśmy lidera zespołu, który chronił nas przed wyższymi kierownikami i śledziliśmy proces scrum.

Projekt był bardzo udany. Było to bardzo stabilne i znacznie lepsze osiągi. Później łatwiej było dodać nowe funkcje. Wierzę więc, że przepisanie kodu można z powodzeniem wykonać, biorąc pod uwagę odpowiednie zasoby i okoliczności.

Na myśl przychodzi tylko jeden quasi-uzasadniony powód: Polityka.

Musiałem przepisać kod od zera, i to miało związek z Polityką. Zasadniczo poprzedni programista, który zarządzał bazą kodową, był zbyt zażenowany, aby udostępnić kod źródłowy nowemu zespołowi, który właśnie został zatrudniony. Uważała, że każda krytyka kodeksu jest krytyką jej osoby, a w rezultacie udostępniła kod reszcie z nas tylko wtedy, gdy została zmuszona. Jest jedyną osobą z administracyjny dostęp do repozytorium, a za każdym razem, gdy poproszono ją o udostępnienie całego źródła, groziła, że zrezygnuje, zabierze całą swoją wiedzę o kodzie i wróci do domu.

Ta baza kodowa ma ponad 15 lat i ma sploty i kontorcje od różnych ludzi o różnych stylach. Żaden z tych stylów najwyraźniej nie wiązał się z komentarzami lub specyfikacjami, przynajmniej w małych porcjach, które nam udostępniła.

Z tylko częściowym kodem dostępny i termin, byłem zmuszony do całkowitego przepisania. W rezultacie zostałem nakrzyczany, ponieważ twierdzono, że spowodowałem poważne opóźnienie, ale po prostu trzymałem głowę nisko i załatwiłem to, zamiast się kłócić.

Polityka może być ogromnym bólem.

Byłem dokładnie w tej sytuacji, ale zamiast całkowitej przeróbki pracowałem nad zmianą rzeczy poprzez proces refaktoryzacji. Problemem, na który wpadłem, była ogromna złożoność kodu, z którym pracowałem - wiele stron okropnego, opartego na szczególnych przypadkach rozwoju, wszystkie oparte na if-cases i zawiłych wyrażeniach regularnych ułożonych w ciągu około dziesięciu lat nieplanowanego wzrostu i ekspansji.

Moim celem było uzyskanie refakturowanej funkcji przez funkcję tak, aby zapewniała to samo wyjście dla te same dane wejściowe, ale działają znacznie bardziej czysto i płynnie pod maską, aby ułatwić przyszły wzrost i poprawić wydajność. Ogólne rozwiązanie było czyste i szybkie, ale naprawianie kodu stało się coraz trudniejsze i bardziej skomplikowane, ponieważ niejasne przypadki w dokumentach przetwarzanych przez system zaczęły się pokazywać, a mój miły czysty kod generowałby wyjście, które było trochę zbyt różne od tego, co zrobił oryginał ( były to strony internetowe, więc inna ilość plików była większa). białe spacje mogą powodować różnego rodzaju problemy z układem w starszych wersjach IE ) w mały i niejasny sposób.

Nie wiem, czy przerobiony kod kiedykolwiek został użyty - opuściłem firmę, zanim miała szansę być w pełni zintegrowana - ale wątpię. Po co używać dwudziestu linijek kodu, skoro piętnaście set poleceń " if " I trzylinijkowe wyrażenia regularne mogły wykonać to samo zadanie?

Jednym z zagrożeń w kompletnym przepisaniu jest to, że Twoja praca jest stale na linii. Jesteś kosztem, który nie przyczynia się do zysku. Kod, który jest do bani, to kod, który zarabia pieniądze.

Ale jeśli naprawisz istniejący kod jeden kawałek na raz, jesteś facetem, który wie, jak działa maszyna do pieniędzy.

Moja odpowiedź brzmi: przepisywać od zera tak często, jak to możliwe .

Spędziłem większość mojej kariery dziedzicząc parujące stosy gnoju, które grzecznie nazywaliśmy "programami", napisanymi przez młodych, niedoświadczonych programistów, których menedżerowie uważali za" gwiazdy rocka". Te rzeczy są zazwyczaj nie do naprawienia, a w końcu spędzasz 10 razy więcej wysiłku, trzymając je kulejąc, jak spędziłbyś po prostu przepisując je od podstaw.

Ale ja również skorzystałem ogromnie zmieniając moją własną pracę okresowo. Każda przeróbka jest szansą, aby robić rzeczy inaczej i potencjalnie lepiej, i powinieneś być w stanie ponownie użyć przynajmniej niektórych części starszej wersji.

To powiedziawszy, nie wszystkie poprawki są dobrym pomysłem. Na przykład Windows Vista.

W pewnym momencie, musisz zmniejszyć swoje straty. Jeśli właśnie odziedziczyłeś tę bazę kodu, możesz wprowadzić zmiany, które mają niezamierzone konsekwencje, a ze względu na brak testów, będą one prawie niemożliwe do znalezienia.

Przynajmniej natychmiast zacznij pisać testy.

Zamiast kompletnego przepisywania od zera, chcesz zacząć refaktoryzację bazy kodu w małych krokach, wprowadzając testy jednostkowe. Na przykład

1. Przenieś zduplikowany kod do wspólnej klasy z testami do ponownego użycia w całym projekcie
2. Wprowadzenie interfejsów do tworzenia oddzielnych testowalnych modułów. Następnie możesz odświeżyć implementację za interfejsem, polegając na testach, aby upewnić się, że niczego nie zepsujesz.

Wolałbym robić rzeczy po trochu, np. tworzyć back-end do bazy danych z modelem danych podczas pracy w tych obszarach (np. najpierw logowanie użytkownika, potem zarządzanie użytkownikami, itd.), i dostosować istniejący front-end do korzystania z nowego back-end (interfejs napędzany, więc można również dodać testy). Pozwoli to zachować istniejący kod z możliwymi nieudokumentowanymi poprawkami i zachowaniami, których nie powtórzyłbyś, rozwijając go ponownie od zera, dodając jednocześnie pewne oddzielenie obaw.

Po jakiś czas będziesz miał migracji około 60% bazy kodu, aby korzystać z nowych back-endów bez pracy jako oficjalny projekt, tylko utrzymanie, więc będziesz w lepszej sytuacji, aby argumentować za czas rozwoju zrobić inne 40%, a kiedy to nastąpi, istniejące klasy front-end będą znacznie zmniejszone w rozmiarze i złożoności. Po pełnej migracji będziesz mógł ponownie użyć nowego modelu zaplecza i komponentów kontrolera, jeśli kiedykolwiek będziesz miał czas na wdrożenie nowego widoku.

Zacznij od napisania specyfikacji technicznej. Jeśli kod jest tak okropny, to założę się, że nie ma też prawdziwej specyfikacji. Więc napisz wyczerpującą i szczegółową specyfikację - i tak musisz napisać specyfikację, jeśli chcesz przepisać od zera, więc czas jest dobrą inwestycją. Należy uważać, aby uwzględnić wszystkie szczegóły dotyczące funkcjonalności. Ponieważ jesteś w stanie zbadać rzeczywiste zachowanie aplikacji, powinno to być łatwe. Zachęcamy do dołączenia sugestii ulepszeń, ale pamiętaj, aby uchwycić wszystkie szczegóły aktualne zachowanie.

W ramach dochodzenia możesz rozważyć napisanie zautomatyzowanych testów systemu do zbadania i udokumentowania oczekiwanego zachowania. Skup się na testowaniu czarnej skrzynki/integracji, a nie na testowaniu jednostek (na co Kod prawdopodobnie i tak nie pozwoli, jeśli jest tak brzydki).

Kiedy masz tę specyfikację, prawdopodobnie odkryjesz, że aplikacja jest znacznie bardziej złożona niż Twoje pierwsze wrażenie i ponownie rozważysz przepisanie od zera. Jeśli zdecydujesz się na stopniowo refaktor zamiast tego spec i testy bardzo ci pomogą. Ale jeśli nadal zdecydujesz się iść do przodu i przepisać, to masz dobrą specyfikację do pracy od teraz, i zestaw testów integracyjnych, które pomogą Ci, gdy Twoja praca zostanie zakończona.

Myślę, że to zależy od dwóch rzeczy:

1) Jak wadliwy jest podstawowy projekt legacy codebase,

2) Czas potrzebny na przepisanie.

1) Firma, dla której pracuję, miała strasznie zaprojektowaną bazę kodową, co sprawiło, że refactor był naprawdę trudny, ponieważ nie mogliśmy refactorować jednego bitu na raz, główny problem nie był z indywidualnymi klasami i funkcjami, ale z ogólnym projektem. Więc podejście refaktoryzacyjne byłoby bardzo trudne. (Jeśli ogólnie projekt był dobry, ale powiedzmy, że poszczególne funkcje miały 300 linii i wymagały zerwania, wtedy refaktoryzacja ma sens).

2) pomimo dużej ilości kodu i bardzo zawiłych, Uruchom procesy. Nasz silnik nie robił za dużo. Więc przepisanie nie trwało tak długo. Czasami menedżerowie nie zdają sobie sprawy z tego, że funkcjonalność setek tysięcy linii kodu może zostać odbudowana w bardzo krótkim czasie.

Próbowaliśmy wyjaśnić to naszemu CTO (małej firmie), ale wciąż myślał, że rewrite będzie do ryzykownego, więc ja i mój współpracownik przepisaliśmy podstawową funkcjonalność silnika w około cztery weekendy. Potem pokazał się naszemu CTO i w końcu został przekonany.

Teraz, jeśli budowa podstawowej funkcjonalności zajęłaby nam sześć miesięcy, nie mielibyśmy wiele na argument.

Istnieje również sprzeczne stwierdzenie w ekonomii, które mówi:]}

Nigdy nie rozliczaj kosztów zatopionych

Według Wikipedii ( https://en.wikipedia.org/wiki/Sunk_cost):

[5]}w ekonomii i podejmowaniu decyzji biznesowych, koszt zatopiony jest kosztem, który został już poniesiony i nie może być odzyskany.

Kiedy koszty utopione są połączone z naciskiem politycznym lub osobistym ego (co menedżer chce przyznać, że podjęli złą decyzję lub nie monitorowali wyników, nawet jeśli było to nieuniknione lub poza ich bezpośrednią kontrolą?), prowadzi do sytuacji zwanej eskalacją zaangażowania (https://en.wikipedia.org/wiki/Escalation_of_commitment ), która jest zdefiniowana jako:

Wzorzec zachowania, w którym jednostka lub grupa, w obliczu coraz bardziej negatywnych skutków jakiejś decyzji, działania i Inwestycji, będzie kontynuować, a nie zmieniać ich kurs-coś, co jest irracjonalne, ale w zgodzie z decyzjami i działaniami wcześniej podjętymi.

Jak to ma zastosowanie do kodu?

Mając teraz dość długą karierę programisty, jednym z najczęstszych wątków, które odkryłem, jest to, że w obliczu trudnej lub brzydkiej bazy kodowej (nawet jeśli jest to nasza własna sprzed dwóch lat), naszym pierwszym instynktem jest chęć wyrzucenia starego, brzydkiego kodu i napisania go od nowa. Jeśli jest to znany kod, to zwykle jest to zrodzeni z faktu, że jesteśmy teraz znacznie bardziej zaznajomieni z pułapkami projektu i wymaganiami biznesowymi niż byliśmy, gdy rozpoczynaliśmy projekt, więc (być może podświadomie) tęsknimy za możliwością naprawienia naszych przeszłych grzechów poprzez wymazanie ich z perfekcją. Jeśli jest to Nieznany kod, często mamy tendencję do nadmiernego uproszczenia wyzwań stojących przed oryginalnymi programistami, pomijając "drobne szczegóły" na rzecz" big-picture " myślenia architektonicznego na poziomie, a często dmuchanie budżetów i ramy czasowe ze względu na brak zrozumienia skomplikowanych drobiazgów biznesowych, które kod miał pierwotnie rozwiązać.

Jest też cała koncepcja długu technicznego, który, podobnie jak dług finansowy, może i będzie narastał do tego stopnia, że baza kodowa staje się technicznie niewypłacalna. Coraz więcej czasu i zasobów jest inwestowanych w rozwiązywanie błędów, gaszenie pożarów i zbyt trudne ulepszenia do tego stopnia, że postęp w przyszłości staje się kosztowny, trudne i niebezpieczne. Projekty trwają dłużej i dłużej z powodu wad i są wycofywane z prac projektowych w celu rozwiązania problemów produkcyjnych. Po godzinach" incydenty " zaczynają być oczekiwane zamiast jakiegoś rzadkiego Blipa. Zamiast wycofywać się i robić wszystko dobrze, aby zwiększyć naszą przyszłą Produktywność( i jakość życia), znajdujemy się w sytuacji, w której jesteśmy zmuszeni do dodawania coraz większego zadłużenia technicznego w celu dotrzymania terminów - technicznego odpowiednika przyjmowania gotówki zaliczki na kartę kredytową, aby dokonać minimalnej płatności na innej karcie.

To wszystko jest powiedziane, nie oznacza to, że powinniśmy przepisywać, o ile to możliwe, ani nie powinniśmy unikać przepisywania kodu roboczego za wszelką cenę. Obie skrajności są potencjalnie marnotrawne, a ta ostatnia ma tendencję do eskalacji zaangażowania (ponieważ za wszelką cenę oznacza z całkowitym pominięciem kosztów, nawet jeśli koszty te całkowicie przewyższają korzyści ). To, co musi nastąpić, jest celem ocena kosztów i korzyści wynikających z przepisywania kodu a dokonywanie przyrostowych ulepszeń. Wyzwaniem jest znalezienie kogoś z zarówno wiedzy i obiektywizmu, aby podjąć tę decyzję prawidłowo. Dla nas programistów, jesteśmy generalnie stronniczy w kierunku przepisywania, ponieważ wydaje się to być o wiele bardziej interesujące i angażujące niż praca nad jakimś gównianym legacy codebase. Menedżerowie biznesu wydają się być stronniczy w innym kierunku, ponieważ przepis narzuca pewne niewiadome z mało zauważalne natychmiastowe korzyści. Rezultatem jest zazwyczaj brak prawdziwej decyzji, która następnie domyślnie kontynuuje wrzucanie godzin do istniejącego kodu, dopóki pewne okoliczności nie wymagają zmiany kierunku (lub programista potajemnie przepisuje kod i zwykle dostaje za niego Klapsy).

Pracowałem na codebases, które były nieco uratowane, choć brzydkie. Nie przestrzegali ustalonych praktyk lub standardów, nie stosowali wzorców, nie byli ładni, ale wykonywali zamierzone funkcje rozsądnie dobrze i były na tyle elastyczne, że można je zmodyfikować, aby zaspokoić przewidywane przyszłe potrzeby w oczekiwanym okresie użytkowania aplikacji. Chociaż nie było to efektowne, było całkowicie akceptowalne, aby utrzymać ten kod przy życiu podczas dokonywania przyrostowych ulepszeń, gdy nadarzyła się okazja. Robienie inaczej przyniosłoby niewiele korzyści poza wyglądem. Powiedziałbym, że większość kodu o którym powinienem to przepisać? pojawia się pytanie, które należy do tej kategorii i znajduję wyjaśniam młodszym programistom z zespołu, że chociaż byłoby świetną zabawą przepisanie YetAnotherLineOfBusinessApp w {Wstaw whizzbang Framework tutaj}, nie jest to ani konieczne, ani pożądane, a oto kilka sposobów, które możemy poprawić...

Pracowałem również nad bazami kodowymi, które były beznadziejne. Były to aplikacje, które ledwo się uruchomiły, zazwyczaj z opóźnieniem i w stanie o ograniczonej funkcjonalności. Zostały napisane w taki sposób, że nikt oprócz oryginału programista miałby szansę zrozumieć, co ostatecznie robi kod. Nazywam to kodem "tylko do odczytu". Po jego napisaniu, każda próba zmiany potencjalnie skutkuje systemową niemożliwą do odczytania awarią nieznanego pochodzenia, prowadzącą do paniki hurtowych przepisań masywnych monolitycznych konstrukcji kodu, które nie służą żadnemu celowi innemu niż edukowanie obecnego dewelopera o tym, co dzieje się ze zmienną sprytnie nazwaną obj_85, zanim wykonanie osiągnie linię 1,209 zagnieżdżonych 7 poziomów deep in if... else..., switch, i foreach... wypowiedzi gdzieś w metodzie DoEverythingAndMakeCoffee(...). Próby refaktoryzacji tego kodu kończą się niepowodzeniem. Każda ścieżka, którą podążasz, prowadzi do kolejnego wyzwania i kolejnych ścieżek, a następnie ścieżek, które się rozgałęziają, a następnie krążą z powrotem do poprzedniej ścieżki, a po dwóch tygodniach refaktoryzacji jednej klasy zdajesz sobie sprawę, że chociaż może lepiej zamknięty, nowy kod jest prawie tak zwariowany i zaciemniony jak stary kod, prawdopodobnie zawiera jeszcze więcej błędów, ponieważ oryginalny kod nie zawiera żadnych błędów. intencja tego, co zmieniłeś, była całkowicie niejasna i nie wiedząc, jakie dokładnie przypadki biznesowe doprowadziły do pierwotnej katastrofy, nie możesz być pewien, że w pełni odtworzyłeś funkcjonalność. Postęp prawie nie istnieje, ponieważ tłumaczenie bazy kodowej jest prawie niemożliwe i coś tak niewinnego jest zmiana nazwy zmiennej lub użycie odpowiedniego typu powoduje wykładniczą ilość niezamierzonych skutków ubocznych.

Próba poprawienia baz kodowych jak wyżej jest ćwiczenie bezcelowe. Refaktoryzacja zwykle skutkuje i tak przepisaniem o 80%, a końcowy wynik nie jest zbliżony do poprawy o 80%. Kończy się to czymś, co jest bardzo niespójne, a nowy kod ma wiele kompromisów, które musiały zostać zaimplementowane w interesie interoperacyjności ze starszym kodem (połowa z nich była niepotrzebna, ponieważ legacy kod, z którym nowy kod musiał współpracować później, i tak zostanie zrefakturowany). Istnieją tylko dwie ścieżki, którymi można podążać... Kontynuuj naliczanie zadłużenia technicznego, hakując "poprawki" i modyfikacje, mając nadzieję, że aplikacja jest przestarzała (lub zostaniesz przeniesiony do innego projektu), zanim upadnie pod własnym ciężarem, lub ktoś podejmie decyzję biznesową i podejmie ryzyko całkowitego przepisania. Nienawidzę obu tych opcji, ponieważ zwykle oznacza to czekanie, aż coś krytycznego się nie powiedzie lub projekt jest znacznie opóźniony w harmonogramie, a następnie spędzasz następne trzy miesiące wieczorami i weekendami próbuję złapać oddech, który prawdopodobnie nigdy nie powinien być żywy.

1. jak dobrze działa istniejący kod? Czy jest niezawodny i stosunkowo wolny od wad?
2. czy ludzie z mojego zespołu są w stanie zrozumieć, co ten kod robi z rozsądnym wysiłkiem? Jeśli sprowadzę doświadczonego dewelopera, czy będzie on / ona w stanie zrozumieć to wystarczająco dużo, aby stać się produktywnym w rozsądnym czas?
3. czy to, co powinno być prostym defektem, wymaga pomiarów geologicznych w czasie, aby naprawić; tak bardzo, że nie jesteśmy w stanie wprowadzić rzeczywistych ulepszeń lub dotrzymać terminów projektu?
4. czy baza kodowa jest tak krucha, a oczekiwany czas życia jest taki, że zdolność aplikacji do dostosowania się do przyszłych przewidywanych potrzeb biznesowych jest wysoce wątpliwa?
5. czy istniejący kod rzeczywiście spełniał pierwotne wymagania funkcjonalności?
Czy Twoja organizacja jest nawet otwarta na inwestując w aplikację, czy ktoś (szczególnie ktoś na wyższym poziomie na wykresie org) otrzyma własne * ss za problem?
6. czy możesz przedstawić finansowe lub oparte na ryzyku uzasadnienie, poparte twardymi faktami, aby uzasadnić biznes dla przepisania?
7. jeśli, po pełnym uwzględnieniu czasu i kosztów przepisania (w tym opracowanie odpowiednich specyfikacji, testowanie zapewnienia jakości, stabilizacja poprodukcyjna i szkolenia, czy nadal ma to sens zacząć przepisywać kod (amerykańscy Programiści myślą tylko w kategoriach czasu kodowania)?
Masz jakiś wybór? Czy jest w ogóle możliwe, aby istniejący kod spełniał wymagania(bo jeśli nie, przepisywanie ogromnych pokosów będzie częścią projektu i będzie uważane za" ulepszenie " zamiast przepisywania)?

Jest stare powiedzenie, które mówi:

Nie ma czegoś takiego jak zły kod. Jest tylko kod, który robi to, co chcesz i kod, który nie.

Klucz do wiedzy, kiedy ponownie napisać leży tam. Czy system robi obecnie to, co chcesz? Jeśli odpowiedź brzmi tak, powolne, ale stałe ulepszenia są najlepszym rozwiązaniem. Jeśli odpowiedź brzmi nie, przepis jest tym, czego chcesz.

Wracając do eseju Joela, mówi o kodzie, który jest brudny, ale oprogramowanie, które jest niezawodne i dostarcza oczekiwaną wartość. Jeśli zamiast tego masz nierzetelny kod pełen poważnych błędów, a to nie obejmowało wszystkich Twoich przypadków użycia. Miałeś rzeczy, które miały tam być, ale nie działają, lub po prostu zniknęły. W tym przypadku, wszystkie małe włosy wyrastające z niego nie są poprawki błędów, ale rak.