it-swarm-eu.dev

Kdy je BIG přepsat odpověď?

Prostě si přečtěte otázka o velkých přepisech a vzpomněl jsem si na otázku, na kterou jsem chtěl odpovědět sám.

Mám hrozný projekt, který mi byl předán, napsaný ve staré Java, používající Struts 1.0, tabulky s nekonzistentními vztahy nebo vůbec žádné vztahy a dokonce i tabulky bez primárních klíčů nebo polí, které měly být primárními klíči, ale nejsou vůbec jedinečné. Nějak většina aplikací "prostě funguje". Většina stránek je znovu použita (zkopírujte vložený kód) a pevně zakódována. Každý, kdo někdy pracoval na projektu, ho proklel v té či oné podobě.

Teď jsem dlouho uvažoval navrhnout vyššímu vedení úplné přepsání této strašlivé aplikace. Pomalu se pokouším v osobním čase, ale opravdu cítím, že si to zaslouží nějaké vyhrazené zdroje, aby se to stalo. Po přečtení článků o velkých přepisech mám druhé myšlenky. A to není dobré, když chci přesvědčit své nadřízené, aby podporovali mé přepisování. (Pracuji v poměrně malé společnosti, takže návrh má možnost být schválen)

TL; DR Kdy je velká přepsání odpovědi a jaké argumenty můžete použít pro její podporu?

288
Jonn

Litujeme, bude to trvat dlouho, ale je to založeno na osobních zkušenostech architekta a vývojáře na několika přepisovacích projektech.

Následující podmínky by měly způsobit, abyste zvážili nějaký druh přepsání. Budu mluvit o tom, jak se rozhodnout, který z nich pak udělat.

  • Doba náběhu vývojáře je velmi vysoká. Pokud to trvá déle než níže (podle úrovně zkušeností), aby se nový vývojář rozšířil, musí být systém přepracován. Časem náběhu mám na mysli dobu, po které je nový vývojář připraven provést svůj první závazek (na malém prvku)
    • Čerstvý z vysoké školy - 1,5 měsíce
    • Stále zelený, ale na jiných projektech pracovali již před - 1 měsícem
    • Střední úroveň - 2 týdny
    • Zkušený - 1 týden
    • Úroveň seniorů - 1 den
  • Nasazení nelze automatizovat z důvodu složitosti stávající architektury
  • Dokonce i jednoduché opravy chyb trvat příliš dlouho kvůli složitosti existujícího kódu
  • Nové funkce trvají příliš dlouho a jsou příliš drahé kvůli vzájemné závislosti na kódové základně (nové funkce nelze izolovat, a proto ovlivňují stávající funkce)
  • Cyklus formálního testování trvá příliš dlouho kvůli vzájemné závislosti existující kódové základny.
  • Příliš mnoho případů použití se provádí na příliš malém počtu obrazovek. To způsobuje problémy s tréninkem pro uživatele a vývojáře.
  • Technologie, kterou současný systém vyžaduje, vyžaduje
    • Kvalitní vývojáři se zkušenostmi s technologií jsou příliš těžko k nalezení
    • Je zastaralý (nelze jej upgradovat na podporu novějších platforem/funkcí)
    • K dispozici je prostě mnohem výraznější technologie vyšší úrovně
    • Náklady na údržbu infrastruktury starší technologie jsou příliš vysoké

Tyto věci jsou zcela zřejmé. Kdy rozhodnout o úplném přepsání versus přírůstkové přestavbě je subjektivnější, a tudíž politicky nabitější. S přesvědčením mohu říci, že kategoricky říci, že je nikdy dobrý nápad je špatný.

Pokud lze systém postupně přepracovat a máte plnou podporu sponzorství projektu pro takovou věc, měli byste to udělat. Tady je ale problém. Mnoho systémů nelze postupně přepracovat. Zde jsou některé z důvodů, s nimiž jsem se setkal a které tomu brání (technické i politické).

  • Technický
    • Spojení komponent je tak vysoké, že změny jedné komponenty nelze izolovat od ostatních komponent. Přepracování jedné komponenty má za následek kaskádu změn nejen sousedních komponent, ale nepřímo všech komponent.
    • Technologický zásobník je tak komplikovaný, že budoucí stavový stav vyžaduje více změn v infrastruktuře. To by bylo nutné i při úplném přepisu, ale pokud je to vyžadováno v přírůstkovém přepracování, ztratíte tu výhodu.
    • Přepracování komponenty má za následek úplné přepsání této komponenty, protože stávající návrh je tak fubar, že není co ušetřit. Opět ztratíte výhodu, pokud je tomu tak.
  • Politický
    • Sponzorům nelze porozumět, že postupné přepracování vyžaduje dlouhodobý závazek k projektu. Většina organizací nevyhnutelně ztratí chuť k pokračujícímu odlivu rozpočtu, který vytváří přírůstkové přepracování. Tato ztráta chuti k jídlu je nevyhnutelná také pro přepis, ale sponzoři budou mít větší sklon pokračovat, protože nechtějí být rozděleni mezi částečně kompletní nový systém a částečně zastaralý starý systém.
    • Uživatelé systému jsou příliš připojeni ke svým „aktuálním obrazovkám“. Pokud tomu tak je, nebudete mít licenci na vylepšení důležité části systému (front-end). Redesign vám umožní obejít tento problém, protože začínají něčím novým. Pořád budou trvat na tom, aby dostali „stejné obrazovky“, ale máte trochu víc munice, abyste se mohli odtlačit.

Mějte na paměti, že celkové náklady na redesiging incrementally jsou vždy vyšší než provedení úplného přepsání, ale dopad na organizaci je obvykle menší. Podle mého názoru, pokud můžete zdůvodnit přepis a máte vývojáře superstar, pak to udělejte.

Udělejte to, pouze pokud si můžete být jisti, že existuje politická vůle to vidět až do konce. To znamená jak výkonný, tak koncový uživatel. Bez toho se vám to podaří. Předpokládám, že proto Joel říká, že je to špatný nápad. Executive and buy-in pro koncového uživatele vypadá pro mnoho architektů jako unicorn s dvěma hlavami. Musíte ji agresivně prodat a kampaň za její pokračování nepřetržitě pokračovat, dokud není kompletní. To je obtížné a mluvíte o tom, jak si vydobýt svou pověst na něčem, co někteří nechtějí vidět úspěch.

Některé strategie úspěchu:

  • Pokud ano, nepokoušejte se převést existující kód. Navrhněte systém od nuly. Jinak ztrácíte čas. Nikdy jsem neviděl ani neslyšel o projektu „konverze“, který nakonec nešťastně skončil.
  • Migrujte uživatele do nového systému po jednom týmu. Identifikujte týmy, které mají největší bolest, se stávajícím systémem a nejprve je migrujte. Nechte je šířit dobré zprávy ústním slovem. Tímto způsobem bude váš nový systém prodáván zevnitř.
  • Navrhněte svůj rámec podle potřeby. Nezačínáme s nějakou budovanou 6měsíční budovou - tento rámec, který nikdy neviděl skutečný kód.
  • Udržujte svůj technologický zásobník co nejmenší. Nepřeceňujte. Můžete přidat technologie podle potřeby, ale jejich odstranění je obtížné. Čím více vrstev máte, tím více práce pro vývojáře musí dělat. Nedělejte to obtížným od začátku.
  • Zapojte uživatele přímo do procesu navrhování, ale nenechte je diktovat jak to udělat. Získejte důvěru tím, že jim ukážete, že jim můžete dát to, co chtějí, pokud budete dodržovat zásady dobrého designu.
328
Michael Meadows

Zúčastnil jsem se dvou velkých přepisů. První byl malý projekt. Druhým byl hlavní produkt softwarové společnosti.

Existuje několik úskalí:

  • přepisuje vždy déle, než se očekávalo.
  • přepisy nemají pro zákazníka přímé účinky/výhody.
  • kapacita věnovaná přepisování není využívána k podpoře zákazníka.
  • ztratíte funkčnost při přepisu, pokud nemáte 100% dokumentaci.

Přepisy jsou jen zřídkakdy skutečnou odpovědí. Můžete refactor hodně z kódu, aniž by ztratil cokoli a bez velkého rizika.

Odpověď může být odpovědí, pokud:

  • přecházíte na jiný jazyk nebo platformu.
  • přepínáte rámce/externí komponenty.
  • stávající kódová základna již nelze spravovat.

Ale důrazně doporučuji pomalý přístup pomocí refaktoringu. Je to méně riskantní a udržujete své zákazníky šťastnými.

112
Toon Krijthe

Je čas na přepsání, když:

Náklady na přepsání aplikace + údržba přepsané aplikace jsou nižší než náklady na údržbu současného systému v čase.

Některé faktory, které způsobují, že údržba stávajícího je dražší:

  • Jazyk je tak starý, že musíte platit lidem, kteří to znají spoustu peněz, aby v něm programovali (COBOL).
  • (ze zkušenosti, bohužel) Systém je na hardwarové architektuře, která je tak stará, že musí prohledat části Ebay a COLLECT, aby přidali do počítače, na kterém běží, protože již nejsou vyráběny. Tomu se říká „podpora životnosti hardwaru“ a je to drahé, protože jak se součásti stávají vzácnějšími, mohou (možná) stoupnout v ceně nebo (nakonec) nakonec dojde.
  • Stalo se tak složitým, že //Here be dragons. komentář je celý váš kód.
  • Nemůžete psát žádné jiné projekty a přidávat společnosti novou hodnotu, protože jste vždy oprava této ošklivé bestie.
74
Ryan Hayes

Pokud požadujete zásadní změnu v architektuře projektu, je možná čas začít znovu.

I s tím budou potenciálně velké řádky kódu, které stojí za to znovu použít ve vašem novém projektu.

Dbejte však spravedlivého varování. Aktuální projekt bude muset nechat otestovat a zdokonalit svá obchodní pravidla s nespočetnými hodinami skutečného využití člověka, což není pravda o projektu zahájeném od nuly.

Pochybuji, že časový rámec nebo pocit střev je vhodným měřítkem tak drastického opatření. Musíte mít jasné, obhájitelné a dobře srozumitelné důvody k účasti na tomto postupu.

17
Dan McGrath

I když souhlasím s odpovědí Kramiiho a Joelovým názorem, jsou chvíle, kdy je vhodné přepsat. U aplikací s dlouhou životností (mluvím jako 10-20 let nebo více) se údržba časem stává stále dražší. To je způsobeno tím, že kód se stává stále více spaghetti-ish, protože původní architektura je obětována za opravy rychlé údržby. Také vývojáři pro starší technologie se stávají vzácnější a dražší. Konečně, hardware začíná stárnout a je těžší a těžší najít nový hardware, operační systémy, frameworky atd., Aby bylo možné spustit starou aplikaci na vrcholu. Podniky se také vyvíjejí a starší systém pravděpodobně nevyhovuje obchodním potřebám organizace, stejně jako by mohl zcela nový systém.

Musíte tedy zvážit veškeré náklady na údržbu a potenciální přínosy nového systému pro podnikání a náklady na přepisování věci od nuly. Být velmi pesimistický ve svých odhadech o nákladech na přepis. Téměř vždy stojí víc a trvá déle, než byste si mysleli.

12
RationalGeek

Stop! Přepisování je téměř nikdy odpověď. Refaktoring je častěji lepší, než ne.


Samozřejmě existují časy , kdy je přepis oprávněný:

  • Přecházíte na novou platformu, kde neexistují migrační nástroje (nebo je nelze napsat levně).
  • Přepsaná aplikace je triviální.
  • Zdrojový kód pro původní aplikaci je ztracen a obnova je dražší než přepisování.
  • Převážná většina obchodních pravidel uzavřených ve stávající aplikaci již neplatí.
  • Existuje jen málo aktivních uživatelů existujícího kódu.
  • Máte zdroj (čas, talent a nástroje) k provedení přepisu.
  • Stávající aplikaci nelze z právních nebo praktických důvodů provozovat v produkčním prostředí.

Abychom pochopili, proč doporučuji refaktoring při přepisování, zvažte, co se podílí na přepisu. Musíš:

  1. Pochopit nuance toho, co stávající aplikace dělá. To obvykle není triviální, pokud berete v úvahu všechna jemná obchodní pravidla, která zapouzdřuje, životní prostředí (lidské i technické), ve kterém působí, a výhody a nevýhody současného řešení. Častěji než ne, jediné místo, kde tyto informace existují (pokud jsou kdekoli), je ve zdrojovém kódu stávající aplikace. Je nešťastné, že jedním z hlavních důvodů pro provedení přepisu je, že existující kód je obtížné pochopit a udržovat.

  2. Rozmnožte tuto funkci (nebo její aktualizovanou verzi) v nové aplikaci, která je testována a spolehlivá. Existující kód nemusí vývojáři pochopit, ale obvykle jej uživatelé pochopí. Nemusí vyhovět jejich současným obchodním potřebám, ale může vám alespoň sdělit, co aplikace dělá za různých okolností.

Velké výhody refaktoringu jsou:

  • Můžete vzít věci po jednom malém kousku najednou.
  • Jakékoli změny lze testovat v kontextu existující funkční aplikace.
  • Hypotézy o tom, jak stávající kód funguje, lze otestovat provedením malých změn a pozorováním, co se stane.
  • Změny mohou být často doručovány uživatelům ve fázích, nikoli všechny najednou.
  • Poučení z raných fází refactoringu může informovat o pozdějších etapách refactoringu.
  • Pokud část procesu opustíte, zůstanou výhody, pokud jde o čistší kódovou základnu (na rozdíl od přepisu, který musí být dokončen do nabídnout uživateli nebo vývojářům jakékoli výhody).

Nezapomeňte také, že pokud přepíšete, je zaručeno, že do nové kódové základny zavedete spoustu nových chyb a nepořádků.

11
Kramii

Tato grafika by mohla pomoci, je to funkce kvality kódové základny a obchodní hodnoty aplikace:

enter image description here

Graf předstírá, že je vodítkem, kdy je přepracování starého softwaru opodstatněné a kdy tomu tak není. Například, pokud má software vysokou obchodní hodnotu a kvalita kódu je nízká, je opětovné inženýrství odůvodněné.

10
Tulains Córdova

Myslím, že jsem ve své kariéře v jediné situaci, kdy je velkým přepisem odpověď:

Fúze společností, obrovské překrytí funkčnosti systémů. Mnoho, mnoho systémů bylo sloučeno a v důchodu, a další stále v procesu.

Zdědil jsem systém od druhé společnosti, která stále žije. Má obrovskou kódovou základnu, která sloužila k podpoře několika oddělení velmi podobných našim, ale se zcela odlišným designem a rámcem. Používá se pouze jeden podnikatelský sektor, který vydělává dost peněz, aby udržel tuto věc naživu ve stavu zombie. Všechny staré odborné znalosti jsou pryč, neexistuje žádná dokumentace. Břemeno podpory je vysoké a každý týden selhává. Nebylo sloučeno s našimi systémy společnosti, protože naše společnost nikdy nepodporovala tento konkrétní obor podnikání, takže nemáme funkčnost ani odborné znalosti.

Vypadá to, že se jedná o jediný případ, kdy je třeba přepsat. Vypadá to, že budu muset přijít na toto stvoření, vytáhnout kousky funkčnosti věnované tomuto podnikání a přepsat kousky, které je třeba přidat do našich stávajících systémů. Jakmile to bude hotovo, naše stávající systémy mohou podporovat tento nový sektor a toto zvíře může být vyřazeno z jeho utrpení. Jinak ztratím rozum.

8
Jay

Pracoval jsem pro malou softwarovou společnost, která měla několik aplikací DOS, které byly upgradovány tak, aby zpracovávaly Y2K, přepsány jako Windows 16-bitová aplikace a pak úplně přepsány jako 32bitová aplikace s jednou další 'malou' funkcí (nakonec využívána pouze jednoho zákazníka), který ovlivnil celou strukturu.

Přesun 16 bitového kódu na 32 mohl být proveden za měsíc jednou osobou, ale NOOOOOOOOO, museli jsme jej přepsat, aby byl Soooooooooo mnohem lepší. Tato věc by mohla být přizpůsobena pro jiná průmyslová odvětví, měla by mít úplné specifikace a psuedo-kód ještě předtím, než začnou. Specifikace byly vytvořeny, ale trvalo to tak dlouho, že nebyl ani čas napsat skutečný kód. Bylo vydáno pozdě, s více chybami než 16 bitů, které se začaly (s verzí v.3.0 a konečně do bodu, kdy jsme to téměř týden zvládli, aniž by někdo nahlásil novou chybu).

Přemýšleli byste, že přepsání stejné aplikace 3-4krát by přineslo určitá vylepšení, ale nemyslím si, že rozhraní front-end GUI může být tolik odůvodněno.

To byla moje první práce v oblasti IT jako vedoucí technické podpory. Měl bych napsat knihu o tom, jak nevyvíjet software pro distribuci. Očividně jsme udělali mnoho chyb, ale skutečnost, že jsme i nadále přepisovali aplikace, nekompetentnost ještě zhoršila.

7
JeffO

Měl jsem případ velmi podobný vašemu, jen kód nevyužíval Struts. Místo toho jsem udělal cílové oblasti, které byly obzvláště mizerné A způsobovaly mnoho problémů. Tento cílený přístup nás postupně zlepšoval.

Během 2 let jsme spolu s vylepšovacími pracemi pracovali na refaktoringu bitů a kusů. Vždy jsme zpracovali úkol „kalení“ do projektového plánu. Zaměřením na konkrétní oblasti, které nefungovaly dobře, jsme získali největší ránu za babku. Věci, které fungovaly, jsme nechali na pokoji. Rozhodující je také to, že tato práce byla provedena v průběhu normálního vývoje a byla uvolněna. Problém s velkým přepsáním je, že odejdete na rok nebo déle a až se vrátíte, všechno se stejně změní a některé z ošklivých chyb se vyhladily a ztratili jste návratnost investic.

Nikdy jsme celou věc nepřepisovali. Přestali jsme však používat tuto platformu pro novou práci a postavili jsme novou čerstvou platformu pro velký nový projekt. To bylo schváleno a dodali jsme skvělý produkt v rozumném množství času.

5
Bill Leeper

Takže tady sedím u svého stolu, začal jsem přepisovat kód pro tento absolutní nepořádek jednoho velkého aspx souboru, databáze za ním a nahrazení rozhraní MS Access do MsSQL.

Tento program asp je plný věcí, jako je

  • include(close.aspx) který uvnitř obsahuje jeden řádek kódu, který uzavírá poslední otevřené připojení k databázi.
  • Starší kód jen náhodně okomentoval
  • Bez ohledu na bezpečnost
  • Špagetový kód, tisíce řádků. Vše v jednom souboru.
  • Funkce a proměnné bez jasného významu za jejich jmény

Pokud někdy potřebujeme provést malou změnu, je to jako hrát pět současných her kal-toh v nočním moru.

Byl jsem najat, abych replikoval funkčnost a vyrobil produkt, který by bylo možné přizpůsobit a prodat ostatním v oboru. Problém je, že tato věc byla napsána za posledních 10 let, aby uspokojila všechny potřeby jednoho podniku (dobře, řekla bych o nich asi pět nebo šest sigma).

Pokud bychom nechtěli produkt prodat, pravděpodobně by nepotřebovali přepis, protože to dělá většinu toho, co chtějí - možná ne elegantně, ale nebylo rozumné utrácet peníze při vytváření pěkného kódu „udělej to samé“.

5
Incognito

Stávající řešení není v měřítku.

Dívám se na tebe, MS Access.

4
user21007

Joel Spolsky o tom má vynikající článek: Věci, které byste nikdy neměli dělat, Část I

Z názvu, který můžete říci, je to trochu jednostranné (mluví o tom, proč byste neměli nikdy házet kód) IMO, je toho hodně pravdy, nedávno jsem viděl video channel9 na 25. výročí Excelu, kde někteří devs řekli, jak i dnes, pokud se podíváte do zdroje, zkontrolujete revizi a nakonec se vrátíte k kódu, který Excel použil a který byl napsán před 20 lety.

Nemůžete si být stoprocentně jistí (i když Netscape dělá chyby (z článku Joels)), [~ # ~] i [~ # ~] Cítil jsem se, jako by Joelův článek byl poslán Bohem, protože můžu být pesimistický a rád zahodím kód, který si myslím, že to dokážu psát lépe podruhé, ale uvědomil jsem si teprve teď to jen stojí lot .

Pro konkrétní odpověď bych řekl , že musíte provést důkladnou analýzu nákladů a hodnoty .

Můj skutečný svět: Aplikace Silverlight Im vyvíjející se v0.6 zatím má nepořádek asynchronních volání, díky kterým je kód tak spletitý. Protože jsem objevil Reaktivní rozšíření tento týden, opravdu chci přepsat většinu kódu, ale co teď řeknu svému zákazníkovi? Program funguje naprosto v pořádku (s některými úniky paměti tho), ale to je jedno? Nemohu jim říct, že jsem bere 2-3 týdny, protože chci něco udělat znovu. Jdu však rozdělit kód a přepsat /hrát s ním ve svém zdarma čas.

Jen moje 2 centy v pořádku !?

4
gideon

Existuje klasický vtip o tom, „kdybych šel do X, nezačal bych odtud“.

Jednou jsem vzal práci, kde hlavní motivací zaměstnavatele bylo přivést talent na palubu a zahájit dlouho opožděné přepisování aplikace kritické pro podnikání. Otázka, na kterou jsem se neptal, zněla: Proč jste v první řadě skončili v této situaci? Měla to být červená vlajka, ať už byla příčina

  • příliš velký tlak na přidání funkcí pro udržování a postupné ovlivňování šelmy,

  • příliš málo schopností v oddělení,

  • příliš malý buy-in od klientů nebo managementu pro přírůstkovou práci,

nebo cokoli, a to způsobí oslavu, dokud problém nedosáhne netolerovatelné úrovně.

Takže souhlasím s Joelem v tom, že masivní přepis je pravděpodobně velmi špatný nápad - , pokud nemáte přesvědčivé důkazy, že všechny základní důvody, proč se hlavní přepisování jeví jako nutné, byly vyřešeno , je pravděpodobné, že se problém v pravý čas opakuje.

2
Julia Hayward

Je to odpověď, když přepis umožňuje organizaci provádět strategii, která poskytuje konkurenční Edge nebo umožňuje, aby lépe sloužila svým zákazníkům nějakým způsobem, který současná architektura nemůže vyhovět.

Místo toho se často stává, že přepisy zmírní starosti se správou:

  • všechno by mělo být v .NET,
  • naši vývojáři říkají, že náš kód je na hovno,
  • technicky zaostáváme,
  • nebudeme schopni najít zdroje pro podporu našeho systému nebo velmi často,
  • je to deset let, takže je čas.

Většina z těchto starostí se nenaplní a pokud ano, lze s nimi zacházet. Ten poslední je však nejhorší. Je to v podstatě: nemáme důvod.

Ano, stejně jako auto, systém začne vykazovat známky opotřebení. To lze zmírnit běžnou údržbou. Víš, co říkají o tom, jak malá preventivní údržba prošla dlouhou cestu. Jako investice bude běžný servis (tj. Refaktoring a standardizace) téměř vždy znamenat nižší náklady než přepisování.

Musíme však předpokládat, že přepracování bude nakonec nezbytné. Stanovte data a předběžně je naplánujte, ale jak se datum blíží k prodlení ve prospěch realizace dalších strategických cílů, dokud nemáte přesvědčivý důvod, jako ...

V posledních letech jsme ztratili příležitost vyhrát velké účty, protože jsme nemohli uspokojit jejich potřeby včas nebo nákladně. Náš systém bude přepsán pomocí rozšiřitelné architektury, která umožňuje připojení přizpůsobení (a nikoli pevné kódování, jak to v současné době děláme). To dramaticky sníží čas a náklady na přijetí zákazníků se speciálními potřebami. Vyhrajeme více účtů a lépe uspokojíme potřeby našich současných zákazníků.

2
Mario T. Lanza

Myslím, že hlavním důvodem, který opravňuje přepisy, jsou změny platformy. Máte-li například grafickou aplikaci pro počítače s operačním systémem Windows a vlastník společnosti se rozhodne, že chce, aby příští verze byla webová aplikace. Ačkoli ne vždy, podle mých zkušeností to bude většinou vyžadovat přepsání, pokud původní vývojáři nenapsali velmi modulární a opakovaně použitelný kód (sotva se stane).

2
Craig

Podle Joela jsou velké přepisy jedinou nejhorší strategickou chybou , kterou může společnost udělat:

Věci, které byste nikdy neměli dělat, Část I

... Je důležité si uvědomit, že když začnete od nuly, není absolutně žádný důvod věřit, že uděláte lepší práci než vy. Poprvé. Za prvé, pravděpodobně nemáte ani stejný programovací tým, který pracoval na verzi jedna, takže ve skutečnosti nemáte „více zkušeností“. Zase uděláte většinu starých chyb znovu a představíte některé nové problémy, které nebyly v původní verzi.

Stará mantra postavená, kterou lze zahodit , je nebezpečná při použití ve velkých komerčních aplikacích. Pokud píšete kód experimentálně, možná budete chtít roztrhat funkci, kterou jste napsali minulý týden, když uvažujete o lepším algoritmu. To je v pořádku. Možná budete chtít změnit třídu, aby bylo používání snadnější. To je v pořádku. Vyhazovat celý program je však nebezpečná pošetilost, a kdyby Netscape skutečně měl nějaký dospělý dozor se zkušenostmi se softwarovým průmyslem, nemuseli by se tak špatně zastřelit do nohy.

2
user3287

Nikdy, vždy refactor - pravda je, že pokud jste kód napsali - nebudete schopni dělat nic lepšího.

Pokud nechcete změnit technologii, kód postrádá jakoukoli strukturu (viděl jsem to už velmi dávno na nějakém PHP web, autor jen kopírovat/vložit spahgetti namísto zahrnout/třída/funkce) nebo jste převzali něco od jiné osoby, která je velmi špatně napsaná.

Všechno by mělo být navrženo jako blackbox. Modulární, Simple API, co je uvnitř ... to je méně důležité :) Pokud máte špagety, můžete ho zavřít uvnitř blackboxu, takže nebude kontaminovat dobrý kód.

2
Slawek

Při přechodu na zcela novou technologii je nutné zajistit požadovanou funkčnost.

„Zcela nové“: pokud plánujete přepsat, ale použít stejnou platformu, pak je lepší řešení reorganizace a uvážlivá restrukturalizace. „Platforma“, jak se zde používá, je poněkud neurčitá - zvažte, že zahrnuje jazyk, a možná přijde na mysl operační systém (od Linuxu po Windows nebo naopak), ale pravděpodobně ne rámec (např. Nahrazení Struts jarem).

„Potřebujeme zajistit požadovanou funkčnost“: právě kolem roku 2000 jsem zahájil projekt na přepsání hlavní komponenty serveru v Java z C++, aby bylo možné zavádět vlákna mimo objekt, mezipaměť objektů, a transakcemi řízenými klienty. V té době existovalo více podprocesových knihoven pro C++, které bychom museli podporovat, a většina podprocesů umožňujících podprocesy by vyžadovala téměř úplné přepsání. Pokud jde o transakce řízené klienty. .. se nestane se starou architekturou.

Ani tehdy si nejsem jistý, že bych přepsal, kromě toho, že jsem měl podrobné znalosti o chování současného systému a že to byl relativně čistý kód, který během svých 11 let života nevyvinul mnoho bradavic.

1
Anon

Dobře si dokážu představit hypotetické scénáře, kde bych mohl vyhodit existující kódovou základnu (hypotetické situace, kdy mají bucky koule nulovou hmotnost a objem, kde se nikdo nestará, pokud ztratíme týdny nebo měsíce produktivity, protože se snažíme přidávat přehlížené funkce a chyby opravuje se do systému a tam, kde je systém tak triviální a nenáviděný organizací, že dokážu nahradit celou věc a armádu serverů poznámkovým blokem ++ a netbookem za deset minut a zvýšit tak produktivitu a morálku všech uživatelů.)

Pro téměř jakýkoli scénář skutečného světa bych však doporučil pouze refaktoring. ^ _ ^. Když se začnou objevovat nezdokumentované právní a obchodní požadavky a začnou se objevovat hackerské věci na poslední chvíli, začne se objevovat příliš mnoho skrytých neočekávaných nákladů na přepisy.

== Refaktoring na místě pro větší dobro a tak ==

Refaktoring starého kódu s pravidelným starým přírůstkovým přístupem

  1. Pokud máte šanci převést na UML a zdokumentovat, jaká maličká architektura existuje.
  2. Pokud používáte řízení verzí, podívejte se na generování některých zpráv o přepisování kódu a zjistěte, které soubory a části souborů byly nejčastěji měněny. Poznamenejte si je, protože to budou pravděpodobně oblasti, které budete chtít nejprve vyřešit.
  3. Než změníte jakýkoli kód, vždy se pokuste přidat nějaké testovací pokrytí (i ty ošklivé plné funkční testy provedou). Pokud se zabýváte rozsáhlou logikou extraktních kódů procedurálních kódů, hodláte se změnit na nějakou rozumně pojmenovanou metodu nebo funkci a pokud je to možné, přidejte několik testovacích případů, které vaši novou metodu ověří. udělejte bohu jakýkoli strašný hack, a pokud je to možné, proveďte změnu, pokud je to něco obyčejně vyladěného, ​​jako je šířka okraje nebo titul, takže bude příště aktualizovat o něco přímější.
  4. Použijte vzor adaptéru a ujistěte se, že skrýváte drsné kousky starého kódu pod kobercem logicky pojmenovaných tříd a metod, takže pro většinu běžných úkolů, které vy a ostatní vývojáři vykonáte, se nemusíte starat o děsivé kousky, které se dějí za záda za těmi pěknými malými čistými metodami a třídami, které jste skryli za starým kódem - jako ty pěkné rodiny, které udržují zdeformované vražedné zombie bývalé členy rodiny ve stodolách, aby nezkazily každodenní chod farma . . . normálně.
  5. Jak budete pokračovat ve snižování a čištění částí kódu, pokračujte ve zvyšování pokrytí testem. Nyní můžete kopat ještě hlouběji a „přepsat“ ještě více kódu, když je to potřeba/žádoucí, se stále rostoucí důvěrou.
  6. Opakujte nebo použijte další refaktoringové přístupy, abyste mohli vylepšit svou kódovou základnu.

Větvení podle abstrakce

  1. Definujte problémové místo v kódu, který chcete odstranit (vrstva perzistence, generátor pdf, mechanismus sčítání faktur, generátor widgetů atd.).
  2. spusťte (zapište, pokud je to nutné) některé funkční testovací případy (automatizované nebo manuální, ale víte automatizované) proti kódové základně, která zacílí na tuto funkci spolu s obecným chováním.
  3. Rozbalte logiku související s touto komponentou z existující zdrojové základny do třídy s určitým rozumným rozhraním.
  4. Ověřte, že veškerý kód nyní používá nové rozhraní k provádění činnosti X, která byla dříve náhodně rozptýlena v celém kódu (Grep kódová základna, přidejte stopu do nové třídy a ověřte stránky, které by ji měly volat, atd.), A že Můžete určit, která implementace bude použita úpravou jednoho souboru. (registr objektů, tovární třída, libovolné IActivityXClass = Settings.AcitivtyXImplementer ();))
  5. znovu spusťte funkční testovací případy, které ověřují, že vše funguje stále se vším, co aktivita X hodí do vaší nové třídy.
  6. Pokud je to možné, napište testy jednotek kolem nové třídy aktivity X obálky.
  7. implementovat novou třídu s méně šílenou logikou špaget než starší implementace, která dodržuje stejné rozhraní jako stará třída.
  8. ověřte, zda nová třída vyhovuje jednotkovým testům, které jste napsali pro starší třídu.
  9. aktualizujte svůj kód změnou registru/tovární metody/cokoli, aby se nová třída použila místo staré třídy.
  10. ověřte, zda vaše funkční testy stále projdou.

Otevřený uzavřený princip a společná obchodní logika/perzistence

Do určité míry se vám může podařit oddělit vaši prezentaci, obchodní a vytrvalostní vrstvu a napsat novou aplikaci, která je plně zpětně kompatibilní se starým řešením, nebo alespoň dokáže zpracovat data zadaná starým řešením. Pravděpodobně bych tento přístup nedoporučoval, ale někdy je to rozumný kompromis času/harmonogramu/zdrojů/požadované nové funkce.

  • Minimálně oddělte prezentační vrstvu od obchodních a perzistenčních vrstev.
  • implementovat novou ui a lepší prezentační vrstvu, která používá stejnou běžnou obchodní a perzistenční vrstvu.
  • Ověřte, že data vytvořená pomocí nového ui nenarušují staré ui. (budete mít v horké vodě, pokud uživatelé nového nástroje přeruší uživatele starého nástroje). Pokud usilujete o plnou zpětnou kompatibilitu, měli byste vše ukládat do stejných vrstev vytrvalosti. Pokud chcete pouze dopředu kompatibilitu s novým nástrojem, použijte novou databázi a nové tabulky nebo tabulky rozšíření ke sledování dat, která nejsou ve starém systému.
  • Pro novou funkčnost a perzistenci je třeba přidat nové tabulky a metody nemění existující starší logiku nebo přidat sloupce, omezení do stávajících tabulek. např. Pokud potřebujete začít sledovat nouzový kontakt zaměstnavatele a některá jiná pole nemění existující tabulku zaměstnanců (nemáme tušení, jaké předpoklady ze starších dat vycházejí z této tabulky), přidejte tabulku rozšíření_id_ zaměstnance, ID_ zaměstnance, nouzové_kontaktní číslo atd.
  • Pomalu migrujte uživatele do nového systému. pokud je to možné, uveďte starý systém do režimu jen pro čtení, nebo přidejte varování, které uživatelům řekne, že po datu X již nebude k dispozici.
  • implementovat do nového uživatelského rozhraní jakoukoli vynechanou funkčnost nebo obchodní požadavky
  • převrátit základnu uživatelů.
  • pokračovat v čištění uživatelských logik a perzistence uživatelů dalších metod refaktoringu.
0
Keith Brings

Řekl bych, že v prostoru Refactor vs Rewrite existuje třetí kategorie ... A to je aktualizace vašich jazykových verzí, kompilátorů a knihoven ... Někdy jen přijetí moderních technik kódování má velkou výhodu.

Vezměte například C #, kód v7 píše mnohem čistší, bezpečnější a stručnější než v2 .. Věci jako Elvis a null coalescing operator pomáhají tuně.

Přepínání kompilátorů může také vdechnout nový život staršímu kódu. Mohou tedy nové knihovny, které by mohly usnadnit práci a implementaci ... Sítě jsou skvělým příkladem celé řady potíží s implementací.

Také - vestavěné linuxové systémy ... Přemýšlejte o instalaci nových nástrojů - přepněte na git od svn. nebo přidat Vi do svého systému atd. atd.

Nemusí to být vždy přepisovatel vs přepisovat .. Vaše architektura pravděpodobně potřebuje zlepšení, ale funguje to ... možná budete muset jen přemýšlet o tom, jak je váš kód napsán atd.

0
visc

Chcete-li se rozhodnout, v jakém okamžiku byste měli začít znovu, musíte zjistit, kde hodnota pokračování na vašem aktuálním projektu nedosahuje hodnoty při zahájení znovu.

Důvod, proč je to tak obtížné, je, že provedete přesný odhad rychlosti vývoje týmu v novém projektu, dokud jej skutečně nespustíte. To znamená, že pokud se pomocí velmi konzervativního odhadu vaší vývojové rychlosti v novém projektu odhaduje, že tento projekt poskytne užitečnou návratnost investice, pak máte obchodní důvod k zahájení znovu.

0
Nobody

Podle mé metriky musíte splnit dvě podmínky, aby bylo možné přepsat:

  1. Po přepsání budou nové funkce snazší/rychlejší/méně buggy psát
  2. Přepsání zabere méně nebo stejnou dobu než přidání nové nové funkce.

I poté chcete omezit rozsah přepisu. Například jsme měli nějaký starší software ve společnosti, který byl napsán v jazyce C++ s myšlenkou programátora C, který nevěděl o modularitě. Konečným výsledkem byl kód speghetti ve formě konečného stavového stroje, který překlenul více tříd a DLL. Měli jsme nový požadavek, který se velmi lišil od předpokladů zabudovaných do kódu a měl být součástí patentované přidané hodnoty společnosti jejím zákazníkům.

Poté, co jsem strávil čas implementací dalších funkcí do kódu, měl jsem opravdu dobrou představu o tom, jak dlouho bude trvat, než zjistím, které z několika příkazů přepínače musím změnit atd. Mým návrhem bylo přepsat část kódu, která byla obrovský konečný stavový stroj - mělo by mi to trvat méně času než rozšíření stávajícího kódu. Podařilo se mi sloučit do jedné DLL to, co bývalo tři), a poskytnout mnohem více objektově orientovanou strukturu, která by výrazně usnadnila provádění kritických nových funkcí a zároveň usnadnila přidat nové funkce.

Existovaly tři další aplikace využívající knihovny, které potřebovaly přepis, takže jsem nechtěl tyto programy přepisovat úplně. Rozsah byl omezen na knihovnu a na to, co bylo nezbytné pro vazbu knihovny na existující software. Moje odhady nebyly zdaleka pryč a práce se vyplatila sama za sebe. Krátce po přepracování jsem dostal za úkol přidat novou funkci. To, co by mi trvalo se starou strukturou trvalo jen týden, s novou strukturou mi trvalo jen den.

0
Berin Loritsch

OP neuvádí rozsah projektu, ale hlavní vodítko, které jsem vzal, bylo „napsáno starým [jazykem/dialektem] pomocí starých [libs]“), které jsou pro mě hlavní hnací silou přepisování. Ve skutečnosti většina projektů, o kterých jsem hovořil s jakoukoli významnou délkou života na trhu, si nakonec uvědomí, že přizpůsobení aktualizací kompilátorům/tlumočníkům/operačním systémům je důležitým úkolem při udržování kódové základny.

Stručně řečeno, naplánoval bych přepisování ve fázích, přičemž nejprve bych upřednostnil aktualizaci v libs. Je možné, že se na cestě budete moci vplížit do dalších optimalizací, ale skutečnost, že plánujete odložit některé změny do pozdější fáze, může být skvělým způsobem, jak zůstat v plánu a vyhnout se „uvíznutí“.

0
MarkHu