Wystarczy przeczytać pytanie dotyczące Wielkich Przepisów i przypomniałem sobie pytanie, na które sam chciałem odpowiedzieć.
Przekazano mi okropny projekt, napisany w starej Javie, przy użyciu Struts 1.0, tabele z niespójnymi relacjami lub w ogóle żadnych relacji, a nawet tabele bez kluczy podstawowych lub pól, które mają być kluczami podstawowymi, ale wcale nie są wyjątkowe. Jakoś większość aplikacji „po prostu działa”. Większość stron jest ponownie wykorzystywana (kopiuj wklejony kod) i zapisana na stałe. Każdy, kto kiedykolwiek pracował nad projektem, przeklął go w takiej czy innej formie.
Teraz od dawna zastanawiałem się nad zaproponowaniem wyższej kadrze kierowniczej całkowitego przepisania tej przerażającej aplikacji. Powoli staram się robić to w czasie osobistym, ale naprawdę czuję, że zasługuje na to, aby to osiągnąć. Po przeczytaniu artykułów o dużych przepisaniach mam inne przemyślenia. I to nie jest dobre, gdy chcę przekonać moich przełożonych, aby poparli moje przepisywanie. (Pracuję w dość małej firmie, więc propozycja może zostać zatwierdzona)
TL; DR Kiedy duży przepisujesz odpowiedź i jakich argumentów możesz użyć do jej wsparcia?
źródło
Odpowiedzi:
Przykro nam, to potrwa długo, ale opiera się na osobistym doświadczeniu zarówno architekta, jak i programisty przy wielu projektach przepisywania.
Poniższe warunki powinny spowodować rozważenie przepisania. Porozmawiam o tym, jak zdecydować, który z nich zrobić później.
Te rzeczy są dość oczywiste. Kiedy decydować o całkowitym przepisaniu w porównaniu z przyrostową przebudową, jest bardziej subiektywna, a zatem bardziej polityczna. Z przekonaniem mogę powiedzieć, że kategoryczne stwierdzenie, że nigdy nie jest dobrym pomysłem, jest błędne.
Jeśli system może być stopniowo przeprojektowywany, a ty masz pełne wsparcie sponsoringowe projektu dla takiej rzeczy, powinieneś to zrobić. Oto problem. Wiele systemów nie może być stopniowo przeprojektowywanych. Oto niektóre z powodów, które napotkałem, które temu zapobiegają (zarówno techniczne, jak i polityczne).
Należy pamiętać, że całkowity koszt stopniowego przeprojektowywania jest zawsze wyższy niż całkowite przepisanie, ale wpływ na organizację jest zwykle mniejszy. Moim zdaniem, jeśli możesz uzasadnić przepisanie, a masz programistów superstar, zrób to.
Rób to tylko wtedy, gdy masz pewność, że istnieje wola polityczna, aby doprowadzić ją do końca. Oznacza to zarówno wpisowe dla kierownictwa, jak i dla użytkowników końcowych. Bez tego zawiedziesz. Zakładam, że właśnie dlatego Joel twierdzi, że to zły pomysł. Dla wielu architektów wpisowe dla użytkowników wykonawczych i użytkowników końcowych wygląda jak dwugłowy jednorożec. Musisz go agresywnie sprzedać i nieustannie prowadzić kampanię, aby go kontynuować. To trudne, a ty mówisz o tym, aby postawić swoją reputację na czymś, czego niektórzy nie będą chcieli zobaczyć.
Niektóre strategie sukcesu:
źródło
Brałem udział w dwóch dużych przepisywaniach. Pierwszy był małym projektem. Drugi był głównym produktem firmy programistycznej.
Istnieje kilka pułapek:
Przepisywanie rzadko jest prawdziwą odpowiedzią. Możesz refaktoryzować większość kodu bez utraty niczego i bez większego ryzyka.
Przepisania mogą być odpowiedzią, jeśli:
Ale zdecydowanie zalecam powolne podejście z wykorzystaniem refaktoryzacji. Jest to mniej ryzykowne i zapewniasz swoim klientom zadowolenie.
źródło
Czas przepisać, gdy:
Koszt przepisania aplikacji + utrzymanie przepisanej aplikacji jest niższy niż koszt utrzymania obecnego systemu w czasie.
Niektóre czynniki, które sprawiają, że utrzymanie obecnego jest droższe:
//Here be dragons.
komentarz jest w całym kodzie.źródło
Jeśli potrzebujesz fundamentalnej zmiany w architekturze projektu, być może czas zacząć od nowa.
Mimo to potencjalnie będą istnieć duże obszary kodu, które nadal warto ponownie wykorzystać w nowym projekcie.
Uważaj jednak na uczciwe ostrzeżenie. Obecny projekt zostanie przetestowany i dopracowany pod kątem reguł biznesowych przy niezliczonych roboczogodzinach, co nie będzie prawdą w przypadku projektu rozpoczętego od zera.
Wątpię, czy przedział czasowy lub przeczucie jest odpowiednią miarą tak drastycznego środka. Musisz mieć jasne , uzasadnione i dobrze zrozumiałe powody, aby wziąć udział w tym postępowaniu.
źródło
Chociaż zgadzam się z odpowiedzią Kramii i opinią Joela, zdarzają się sytuacje, w których należy przerobić. W aplikacjach długowiecznych (mówię o 10-20 lat lub więcej) utrzymanie z czasem staje się coraz droższe. Wynika to z faktu, że kod staje się coraz bardziej spaghetti, ponieważ oryginalna architektura jest poświęcana dla szybkich łat konserwacyjnych. Ponadto programiści starszych technologii stają się coraz rzadsi i drożsi. Wreszcie, sprzęt zaczyna się starzeć i coraz trudniej jest znaleźć nowy sprzęt, systemy operacyjne, frameworki itp. Do uruchomienia starej aplikacji. Ponadto firmy ewoluują i najprawdopodobniej starszy system nie będzie odpowiadał potrzebom biznesowym organizacji, tak jak zupełnie nowy system.
Musisz więc wyważyć wszystkie bieżące koszty utrzymania, a także potencjalne korzyści płynące z nowego systemu dla firmy, z kosztami przepisania rzeczy od zera. Bądź bardzo pesymistyczny w swoich szacunkach dotyczących kosztu przepisania. Prawie zawsze kosztuje więcej i trwa dłużej niż mogłoby się wydawać.
źródło
Zatrzymać! Przepisywanie prawie nigdy nie jest odpowiedzią. Najczęściej refaktoryzacja jest lepszym rozwiązaniem.
Oczywiście, są chwile, kiedy przepisać to uzasadnione:
Aby zrozumieć, dlaczego zalecam refaktoryzację zamiast przepisywania, zastanów się, co jest związane z przepisywaniem. Musisz:
Poznaj niuanse tego, co robi istniejąca aplikacja. Nie jest to zwykle trywialne, gdy weźmie się pod uwagę wszystkie subtelne reguły biznesowe, które zawiera, środowisko (ludzkie i techniczne), w którym działa, oraz zalety i wady obecnego rozwiązania. Częściej niż nie, jedynym miejscem, w którym te informacje istnieją (jeśli gdziekolwiek są), jest kod źródłowy istniejącej aplikacji. Szkoda, że jednym z głównych powodów przepisywania jest to, że istniejący kod jest trudny do zrozumienia i utrzymania.
Odtwórz tę funkcję (lub jej zaktualizowaną wersję) w nowej, przetestowanej i niezawodnej aplikacji. Istniejący kod może nie zostać zrozumiany przez programistów, ale zazwyczaj jest dobrze zrozumiany przez jego użytkowników. Może nie spełniać ich bieżących potrzeb biznesowych, ale mogą przynajmniej powiedzieć ci, co robi aplikacja w różnych okolicznościach.
Dużymi zaletami refaktoryzacji są:
Pamiętaj też, że jeśli przepiszesz, masz gwarancję wprowadzenia wielu nowych błędów i bałaganu w nowej bazie kodu.
źródło
Ta grafika może pomóc, jest to funkcja jakości bazy kodu i wartości biznesowej aplikacji:
Wykres udaje, że jest wskazówką, kiedy przeprojektowanie starszego oprogramowania jest uzasadnione, a kiedy nie. Na przykład, jeśli oprogramowanie ma wysoką wartość biznesową, a jakość kodu jest niska, uzasadnione jest ponowne zaprojektowanie.
źródło
Myślę, że jestem jedyną sytuacją w mojej karierze, w której duże przepisanie jest odpowiedzią:
Fuzja firm, ogromne nakładanie się funkcjonalności systemów. Wiele systemów zostało połączonych i wycofanych, a inne wciąż są w trakcie procesu.
Odziedziczyłem system od innej firmy, która nadal żyje. Ma ogromną bazę kodu, która obsługiwała wiele działów bardzo podobnych do naszego, ale z zupełnie innym wyglądem i strukturami. Został z niego tylko jeden sektor biznesowy, który zarabia wystarczająco dużo pieniędzy, aby utrzymać to przy życiu w stanie zombie. Cała stara wiedza zniknęła, nie ma dokumentacji. Obciążenie związane z obsługą jest wysokie, a awarie co tydzień. Nie został włączony do systemów naszych firm, ponieważ nasza firma nigdy nie wspierała tego konkretnego sektora działalności, więc nie mamy funkcjonalności ani wiedzy specjalistycznej.
Wygląda na to, że jest to jedyny przypadek, w którym konieczne jest przepisanie. Wygląda na to, że będę musiał zrozumieć tego giganta, wyciągnąć elementy funkcjonalności dedykowane dla tego biznesu i przepisać elementy, które należy dodać do naszych istniejących systemów. Kiedy to się stanie, nasze istniejące systemy będą w stanie obsługiwać ten nowy sektor, a bestia może zostać wyeliminowana z nędzy. W przeciwnym razie stracę zdrowie psychiczne.
źródło
Pracowałem dla małej firmy programistycznej, która miała kilka aplikacji DOS, które zostały zaktualizowane do obsługi Y2K, przepisane jako 16-bitowa aplikacja Windows, a następnie całkowicie przepisane jako aplikacja 32-bitowa z jedną dodatkową „małą” funkcją (ostatecznie wykorzystywaną tylko przez jeden klient), który wpłynął na całą strukturę.
Przeniesienie 16-bitowego kodu do 32 mogło być wykonane w ciągu miesiąca przez jedną osobę, ale NOOOOOOOOO, musieliśmy go przepisać, aby Soooooooooo było znacznie lepsze. Ta rzecz może być przystosowana do innych gałęzi przemysłu, miałaby pełną specyfikację i kod psuedo, zanim jeszcze zaczęły. Specyfikacje zostały utworzone, ale zajęło to tak dużo czasu, że nie było nawet czasu na napisanie prawdziwego kodu. Został wydany późno, z większą liczbą błędów niż 16-bitowy „zaczął” (był na wersji 3.0 i wreszcie do tego stopnia, że prawie zrobiliśmy to tydzień bez kogoś zgłaszającego nowy błąd).
Można by pomyśleć, że przepisanie tej samej aplikacji 3-4 razy przyniosłoby pewne ulepszenia, ale nie sądzę, żeby interfejs GUI był tak uzasadniony.
To była moja pierwsza praca IT jako szef działu wsparcia technicznego. Powinienem napisać książkę o tym, jak nie tworzyć oprogramowania do dystrybucji. Oczywiście popełniliśmy wiele błędów, ale fakt, że nadal przepisywaliśmy aplikacje, spotęgował niekompetencję.
źródło
Miałem przypadek bardzo podobny do twojego, ale kod nawet nie używał Struts. Zamiast tego wybrałem obszary docelowe, które były wyjątkowo kiepskie ORAZ powodujące wiele problemów. To ukierunkowane podejście poprawiło nas stopniowo.
W ciągu 2 lat pracowaliśmy nad refaktoryzacją bitów i elementów, a także pracami ulepszającymi. Zawsze pracowaliśmy nad zadaniem „hartowania” w planie projektu. Koncentrując się na konkretnych obszarach, które nie działały dobrze, uzyskaliśmy największe zyski. Rzeczy, które działały, zostawiliśmy w spokoju. Krytyczne jest również to, że praca ta została wykonana w trakcie normalnego rozwoju i została wydana. Problem z dużym przepisywaniem polega na tym, że robisz to przez rok lub dłużej, a potem, kiedy wracasz, wszystkie rzeczy i tak się zmieniły, a niektóre z paskudnych błędów zostały wygładzone i straciłeś ROI.
Nigdy nie napisaliśmy tego od nowa. Przestaliśmy jednak używać tej platformy do nowej pracy i przygotowaliśmy nową świeżą platformę do nowego dużego projektu. Zostało to zatwierdzone i dostarczyliśmy świetny produkt w rozsądnym czasie.
źródło
Więc tutaj siedzę przy biurku i zacząłem ponownie pisać kod dla tego absolutnego bałaganu jednego dużego pliku aspx, bazy danych za nim i zastępując interfejs MS Access MsSQL.
Ten program asp jest zaśmiecony takimi rzeczami jak
include(close.aspx)
który w środku ma jeden wiersz kodu, który zamyka ostatnie otwarte połączenie z bazą danych.Jeśli kiedykolwiek będziemy musieli wprowadzić niewielką zmianę, to tak, jakbyśmy grali w pięć jednoczesnych gier kal-toh w trybie koszmaru.
Zostałem zatrudniony do replikacji funkcjonalności i stworzenia produktu, który można dostosowywać i sprzedawać innym w branży. Problem polega na tym, że ta rzecz została napisana w ciągu ostatnich 10 lat, aby zaspokoić każdą potrzebę biznesową (cóż, i tak powiedziałbym o pięciu lub sześciu sigmach z nich).
Gdybyśmy nie chcieli sprzedawać produktu, prawdopodobnie nie potrzebowaliby ponownego napisania, ponieważ robi większość tego, czego chcą - być może nie elegancko, ale wydawanie pieniędzy na robienie dobrego kodu nie było rozsądne. 'Zrób to samo.'
źródło
Joel Spolsky ma doskonały artykuł na ten temat: Rzeczy, których nigdy nie powinieneś robić, część I
Po tytule, który można powiedzieć, jest on jednostronny (mówi o tym, dlaczego nigdy nie należy rzucać kodu) IMO, jest w tym wiele prawdy, ostatnio widziałem wideo channel9 w 25. rocznicę Excela, gdzie niektórzy deweloperzy powiedzieli, jak to zrobić nawet dzisiaj, jeśli zajrzysz do źródła, sprawdzisz wersję i wrócisz do kodu używanego przez program Excel, który został napisany 20 lat temu.
Nie można być w 100% pewna (gdy nawet Netscape popełnia błędy (od Joels artykułu)), mam ochotę artykułu Joela był Bóg posłał, bo mogę być pesymistą i miłości wyrzucać kod myślenie zawsze mogę napisać to lepiej drugi czas, ale zdałem sobie sprawę, że dopiero teraz to dużo kosztuje .
Aby dać konkretną odpowiedź, chciałbym tylko powiedzieć, że musisz przeprowadzić dokładną analizę kosztów w porównaniu do wartości .
Mój świat rzeczywisty: aplikacja Silverlight, w której do tej pory pracuję nad wersją v0.6, zawiera wiele wywołań asynchronicznych, które powodują, że kod jest tak zawiły. Odkąd odkryłem Reactive Extensions w tym tygodniu, naprawdę chcę ponownie napisać większość kodu, ale teraz co mam powiedzieć mojemu klientowi? Program działa idealnie dobrze (z pewnymi przeciekami pamięci), ale czy ich to nie obchodzi? Nie mogę im powiedzieć, że biorę jeszcze 2-3 tygodnie, bo chcę coś zrobić ponownie. Mam jednak zamiar rozgałęzić kod i ponownie go napisać / grać w wolnym czasie.
Tylko moje 2 centy ok !?
źródło
Istniejące rozwiązanie nie jest skalowane.
Patrzę na ciebie, MS Access.
źródło
Według Joela duże przepisywania są najgorszym strategicznym błędem, jaki może popełnić firma:
Rzeczy, których nigdy nie powinieneś robić, część I
źródło
Nigdy, zawsze refaktoryzuj - prawda jest taka, że jeśli kod został napisany przez ciebie - nie będziesz w stanie zrobić nic lepszego.
O ile nie chcesz zmienić technologii, w kodzie brakuje jakiejkolwiek struktury (widziałem go bardzo dawno temu na jakiejś stronie PHP, autor po prostu kopiuje / wkleja spahgetti zamiast include / class / function) lub przejąłeś coś od innej osoby, która bardzo źle napisane.
Wszystko powinno być zaprojektowane jako blackbox. Modułowy, prosty interfejs API, co jest w środku ... to mniej ważne :) Jeśli masz spaghetti, być może będziesz w stanie zamknąć go w blackboksie, aby nie zanieczyścił dobrego kodu.
źródło
Myślę, że głównym powodem uzasadniającym przepisywanie są zmiany platformy. Na przykład, jeśli masz aplikację GUI dla systemu Windows, a właściciel firmy zdecyduje, że chce, aby następna wersja była aplikacją internetową. Chociaż nie zawsze, z mojego doświadczenia wynika, że będzie to wymagało przepisania, chyba że pierwotni programiści napisali bardzo modułowy i wielokrotnego użytku kod (rzadko się zdarza).
źródło
Jest taki klasyczny żart: „gdybym jechał na XI, nie zacząłbym od tego miejsca”.
Raz podjąłem pracę, gdzie główną motywacją pracodawcy było sprowadzenie talentu na pokład, aby uruchomić od dawna opóźnione przepisanie aplikacji o krytycznym znaczeniu dla biznesu. Pytanie, którego nie zadałem, brzmiało: dlaczego znalazłeś się w takiej sytuacji? Powinna to być czerwona flaga, niezależnie od tego, czy była tego przyczyna
zbyt duży nacisk, aby dodać funkcjonalność do utrzymania i stopniowego refaktoryzacji bestii,
zbyt mało umiejętności w dziale,
zbyt małe zaangażowanie ze strony klientów lub kierownictwa do pracy przyrostowej,
czy cokolwiek innego, a to powoduje odejście, aż problem osiągnie nie do zniesienia poziom.
Więc zgodzę się z Joelem, że masowe przepisywanie jest prawdopodobnie bardzo złym pomysłem - chyba że masz mocne dowody, że wszystkie podstawowe przyczyny, dla których poważna przeróbka wydaje się tak konieczna, zostały rozwiązane , istnieje duże prawdopodobieństwo zamierzam powtórzyć problem we właściwym czasie.
źródło
Jest to odpowiedź, gdy przepisanie pozwala organizacji realizować strategię, która zapewnia przewagę konkurencyjną lub pozwala lepiej obsługiwać klientów w taki sposób, że obecna architektura nie jest w stanie tego zaakceptować.
Zamiast tego przepisywanie często zdarza się, aby zmniejszyć obawy związane z zarządzaniem:
Większość tych zmartwień nie zmaterializuje się, a jeśli tak, to można je rozwiązać. Ten ostatni jest jednak najgorszy. Zasadniczo: nie mamy powodu.
Tak, podobnie jak samochód, system zacznie wykazywać oznaki zużycia. Można to złagodzić poprzez rutynowe serwisowanie. Wiesz, co mówią o tym, jak mała konserwacja zapobiegawcza przechodzi długą drogę. Jako inwestycja rutynowe serwisowanie (tj. Refaktoryzacja i standaryzacja) prawie zawsze wiąże się z niższymi kosztami niż przepisywanie.
Musimy jednak przewidzieć, że przepisanie będzie ostatecznie konieczne. Ustal daty i wstępnie je zaplanuj, ale w miarę zbliżania się terminu, aby realizować inne strategiczne cele, dopóki nie będziesz miał ważnego powodu, takiego jak ...
W ostatnich latach straciliśmy okazję do zdobywania dużych kont, ponieważ nie mogliśmy zaspokoić ich potrzeb w odpowiednim czasie lub kosztownie. Nasz system zostanie przepisany przy użyciu rozszerzalnej architektury, która pozwala na podłączanie dostosowań (i nie jest zakodowana na stałe, jak obecnie). To radykalnie skróci czas i koszty przystosowania klientów o specjalnych potrzebach. Wygrywamy więcej kont i lepiej zaspokajamy potrzeby naszych obecnych klientów.
źródło
Przy przejściu do całkowicie nowej technologii potrzebna jest pożądana funkcjonalność.
„Zupełnie nowy”: jeśli planujesz przepisać, ale używasz tej samej platformy, refaktoryzacja i rozsądna restrukturyzacja są prawie na pewno lepszym rozwiązaniem. „Platforma”, jak tutaj użyto, jest nieco niejasna - weź pod uwagę, że obejmuje ona język i być może system operacyjny (rozciągający się z Linuksa na Windows lub odwrotnie), ale prawdopodobnie nie jest strukturą (np. Zastępuje Struts Springem).
„Potrzebne do zapewnienia pożądanej funkcjonalności”: około 2000 roku zainicjowałem projekt przepisania ważnego komponentu serwerowego w Javie z C ++, aby umożliwić gotowe wątki, buforowanie obiektów i transakcje kontrolowane przez klienta. W tym czasie istniało wiele bibliotek wątków dla C ++, które musieliśmy obsługiwać, a obsługa wątków w dużej części naszego kodu bazy danych wymagałaby prawie całkowitego przepisania. Jeśli chodzi o transakcje kontrolowane przez klienta ... nie stanie się to ze starą architekturą.
Nawet wtedy nie jestem pewien, czy zrobiłbym to na nowo, poza tym, że miałem szczegółową wiedzę na temat zachowania obecnego systemu i był to stosunkowo czysty kod, który nie rozwinął zbyt wielu brodawek w ciągu 11 lat swojego życia.
źródło
Aby zdecydować, od kiedy powinieneś zacząć od nowa, musisz ustalić, gdzie wartość kontynuacji bieżącego projektu jest mniejsza niż wartość rozpoczynania od nowa.
Powodem tego jest to, że dokonujesz dokładnego oszacowania prędkości rozwoju zespołu w nowym projekcie, dopóki go nie uruchomisz. To powiedziawszy, jeśli, używając BARDZO konserwatywnego oszacowania twojej prędkości rozwoju w nowym projekcie, szacuje się, że projekt zapewnia opłacalny zwrot z inwestycji, to masz uzasadnienie biznesowe, aby zacząć od nowa.
źródło
W przypadku moich danych musisz spełnić dwa warunki, aby uzasadnić przepisanie:
Nawet wtedy chcesz ograniczyć zakres przepisywania. Na przykład mieliśmy w firmie trochę starszego oprogramowania napisanego w C ++ z myślą o programistach C, którzy nie wiedzieli o modułowości. Efektem końcowym był kod speghetti w postaci skończonej maszyny stanów, która obejmowała wiele klas i bibliotek DLL. Mieliśmy nowy wymóg, który bardzo różnił się od założeń wbudowanych w kod i miał stanowić część opatentowanej przez firmę wartości dodanej dla jej klientów.
Po spędzeniu czasu z kodem na implementacji innych funkcji, miałem naprawdę dobry pomysł, ile czasu zajmie ustalenie, które z kilku instrukcji switch muszę zmienić itp. Moją propozycją było przepisanie sekcji kodu, która była ogromna skończona maszyna stanów - powinno to zająć mi mniej czasu niż rozszerzenie istniejącego kodu. Udało mi się skonsolidować w jedną bibliotekę DLL, która kiedyś była trzy, i zapewnić znacznie bardziej zorientowaną obiektowo strukturę, która znacznie ułatwiłaby wykonanie nowej, krytycznej funkcjonalności wraz z ułatwieniem dodania nowej funkcjonalności.
Były też trzy inne aplikacje korzystające z bibliotek, które wymagały przepisania, więc nie chciałem całkowicie przepisywać tych programów. Zakres był ograniczony do biblioteki i tego, co było konieczne do powiązania biblioteki z istniejącym oprogramowaniem. Moje prognozy nie były daleko, a praca się zwróciła. Wkrótce po przeprojektowaniu miałem za zadanie dodać nową funkcję. To, co zajęłoby mi tydzień ze starą konstrukcją, zajęło mi tylko dzień z nową konstrukcją.
źródło
OP nie wskazuje zakresu projektu, ale główną wskazówką, którą podjąłem, było „napisane w starym [języku / dialekcie] przy użyciu starych [libs]”, które według mnie są głównymi sterownikami przepisywania. W rzeczywistości większość projektów, na których prowadziłem znaczącą długowieczność rynku, w końcu zdaje sobie sprawę, że dostosowanie aktualizacji do kompilatorów / interpretatorów / systemów operacyjnych jest ważnym zadaniem w utrzymaniu bazy kodu.
Krótko mówiąc, planowałbym ponowne pisanie etapami, najpierw nadając priorytet aktualizacji w libs. Być może po drodze możesz się zakraść w innych optymalizacjach, ale fakt, że planujesz odroczyć niektóre zmiany w późniejszej fazie, może być świetnym sposobem na dotrzymanie harmonogramu i uniknięcie „utknięcia”.
źródło
Cóż, mogę sobie wyobrazić hipotetyczne scenariusze, w których mógłbym po prostu wyrzucić istniejącą bazę kodu (hipotetyczne sytuacje, w których kulki mają zerową wagę i objętość, gdzie nikogo to nie obchodzi, jeśli stracimy tygodnie lub miesiące produktywności, starając się dodać przeoczone funkcje i błąd poprawki w systemie, a gdy system jest tak trywialny i nienawidzony przez organizację, że mogę zastąpić całą rzecz i armię serwerów notatnikiem ++ i netbookiem w ciągu dziesięciu minut, a także zwiększyć produktywność i moralność wszystkich.)
Jednak w przypadku prawie każdego scenariusza z prawdziwego świata po prostu polecam refaktoryzację na miejscu. ^ _ ^. Zwykle pojawia się zbyt wiele ukrytych, nieprzewidzianych kosztów, aby przepisać, gdy pojawiają się nieudokumentowane wymagania prawne i biznesowe, a ostatnia minuta wspólnego hakowania rzeczy w ostatniej chwili zaczyna się pojawiać.
== Refaktoryzacja na miejscu dla większego dobra i rzeczy ==
Refaktoryzacja starszego kodu za pomocą zwykłego starego podejścia przyrostowego,
Rozgałęzienie według abstrakcji
Otwarta zasada zamknięta i wspólna warstwa logiki biznesowej / trwałości
Do pewnego stopnia możesz nie być w stanie oddzielić warstwy prezentacji, biznesu i trwałości oraz napisać nową aplikację, która jest w pełni kompatybilna wstecz ze starszym rozwiązaniem, lub przynajmniej może obsługiwać dane wprowadzone przez starsze rozwiązanie. Prawdopodobnie nie zaleciłbym tego podejścia, ale czasami jest to rozsądny kompromis czasu / harmonogramu / zasobów / wymaganej nowej funkcjonalności.
źródło
Powiedziałbym, że jest trzecia kategoria w przestrzeni Refactor vs. Rewrite ... A to aktualizuje twoje wersje językowe, kompilatory i biblioteki ... Czasami po prostu zastosowanie nowoczesnych technik kodowania ma wielką zaletę.
Weźmy na przykład C #, kod v7 pisze o wiele czystsze, bezpieczniejsze i bardziej zwięzłe niż v2 .. Rzeczy takie jak Elvis i operator koalescencji zerowej pomagają tonować.
Przełączanie kompilatorów może także tchnąć nowe życie w starszy kod. Podobnie mogą być nowe biblioteki, które mogą ułatwić pracę i wdrożenie ... Sieć jest doskonałym przykładem spektrum trudności związanych z implementacją.
Wbudowane systemy Linux ... Pomyśl o instalacji nowych narzędzi - przełącz się na git z svn. lub dodaj Vi do swojego systemu itp.
Nie zawsze musi to być refaktoryzacja kontra przepisywanie .. Twoja architektura prawdopodobnie wymaga ulepszeń, ale działa ... może po prostu musisz pomyśleć o tym, jak napisany jest kod itp.
źródło
Nie sądzę, że kiedykolwiek widziałem ludzi przepisujących starszą aplikację.
To, co się dzieje, polega na tym, że ludzie piszą zupełnie nowe aplikacje o innej architekturze, technologiach itp., Które mają pewne cechy wspólne z poprzednią generacją. Nazywa się to app 2.0, ale w rzeczywistości ma niewiele wspólnego z oryginałem.
Ale tak naprawdę nie jest to „przepisywanie” oryginału w tym sensie, że próbujesz osiągnąć parzystość funkcji.
źródło