Districare un pasticcio di software, ora di Big Rewrite?

Question

Recentemente ho iniziato un lavoro sapendo che le pratiche della società avevano bisogno di aiuto: nessun controllo del codice sorgente, nessun bug tracking, nessun test automatico. Mi hanno detto che il loro codice di applicazione non era buono.

Che understatement.

Il loro codice è un disastro immondo di asp classico, vb.net non orientato agli oggetti (ciao recordset!), Fogli di stile incorporati, ecc. Il database è un incubo: 500 tabelle dispari, metà delle quali sembrano essere vecchie spazzatura, centinaia e centinaia di sproc non documentati. Gli sproc sono pieni di logica aziendale, logica ui (molti comandi PIVOT), ecc.

Esistono quattro applicazioni Web mission critical sovrapposte che utilizzano questo pasticcio e, inutile dirlo, la maggior parte del lavoro è stata eseguita da consulenti esterni chi non restituisce più le chiamate della società. (Chi può biasimarli?)

La gestione è sconcertata dall'incapacità del proprio team Web di soddisfare i requisiti aziendali. Ho avuto un certo successo nello spiegare cosa è andato storto: "immagina una palla di nastro adesivo e fili di sette piani alti ..."

Naturalmente, vogliono risposte, non reclami. Ho considerato un Big Rewrite, ma sembra pieno di rischi. Sono incoraggiato a fare una grande vittoria presto, ma non sono sicuro da dove cominciare. Gradirei qualsiasi suggerimento che potresti essere in grado di offrire.

sto pensando di avvicinarsi in questo modo:

• EDIT: ottenere TFS 2010
• Uccidete tutti "classico" asp-se non può essere compilato, non possiamo essere ancora certo se abbiamo tutti i riferimenti .
• Trova chi utilizza quali sprocs/tabelle tramite ricerca testo , elimina elementi non utilizzati
• Riscrivi la funzionalità in pezzi, ad es. sostituire il carrello acquisti asp con qualcosa OO.

O alternativamente, continuiamo a sbattere nastro adesivo sul disordine esistente mentre costruiamo il One True System sul lato.

Gradirei qualsiasi suggerimenti/storie di guerra/offerte di lavoro si alternano, ecc

Answer 1

È difficile sapere cosa fare in questo tipo di casi, in quanto né mantenere il vecchio sistema né riscrivere il sistema è molto allettante. Un problema con la riscrittura è che è probabile che molte conoscenze siano incorporate nei casi speciali del sistema, ecc. E se il codice è veramente terribile probabilmente non sarai in grado di estrarre facilmente tale conoscenza se riscrivi da zero .

Un'alternativa a una riscrittura di base consiste nel fare ciò che io chiamo "l'ascia di George Washington". È come la vecchia barzelletta sul ragazzo che ha l'ascia che George Washington usava per abbattere il ciliegio - ovviamente ha dovuto sostituire la maniglia tre volte, e la testa cinque volte.

Quando è necessario aggiungere funzionalità o apportare modifiche al sistema, accedere e prima aggiungere test che coprano la maggior parte delle funzionalità della parte che è necessario modificare come è possibile gestire. Quindi rifatta le parti del codice che è necessario essere in grado di comprendere per aggiungere la funzione o apportare la modifica, eseguendo i test ad ogni modifica. Non è neanche una cattiva idea eseguire qualsiasi test funzionale che tu abbia quanto più spesso è pratico. Alla fine avrai riscritto l'intero sistema, o almeno avrai murato via tutte le cose più brutte, ma non avrai dovuto interrompere tutto lo sviluppo per un periodo indefinito di tempo per riscrivere da zero.

Ovviamente ci sono alcuni aspetti negativi di questo approccio - funzionalità e modifiche saranno più lente di quanto dovrebbero essere per un bel po ', fino a quando le cose non saranno sotto controllo. Alla fine devi considerare tutti i fattori, pesarli e prendere una decisione, potrebbe essere che riscrivere da zero sia l'opzione migliore.

Answer 2

Io non credo che si possa mantenere questo pasticcio e lavorare con esso. Ma suggerisco di provare a creare Facade con questo vecchio garbage code fino a quando non lo riscrivi tutto. E poi riscrivi parti di esso parte per parte.

Creazione di una facciata non dovrebbe richiedere molto tempo (almeno non molto in confronto a Big Rewrite). E dopo potrai iniziare subito a migliorare il software usando la nuova API pulita. E quando avrai del tempo libero, riscriverai la vecchia parte di codice della spazzatura usando il tuo modo di codificare.

Ovviamente, potrebbe essere impossibile creare una facciata per il tipo di codice che si possiede. È?

Answer 3

Il nastro isolante funziona e non è facile ricostruire un edificio di 7 piani. IMO, continuerei a battere sul nastro mentre pianifico un nuovo sistema sul lato se il capo è disposto a pagarti per l'enorme quantità di ore che richiederebbe.Spesso trovo la gestione che vuole vedere il "progresso" più di ogni altra cosa, nel senso che una nuova funzionalità scadente, codificata ma appariscente, raccoglierà molti più oggetti di scena di una ricostruzione completa del sistema che alla fine sembra la stessa cosa. Boss probabilmente non si preoccupa molto di un carrello OO rispetto a un carrello non OO. Non è giusto, lo so, e in un posto di lavoro ideale non sarebbe il caso. Solo i miei 2 centesimi. Non è difficile impostare un repository git o svn, tuttavia, e questo è un passo nella giusta direzione. I sistemi di ticketing RT o Trac possono essere utili per il tracciamento dei bug e le richieste di funzionalità.

Answer 4

brian: basta tenere lo schiaffo sul nastro adesivo e scansionare collegato per nuovi lavori :).

seriamente, è necessario presentare un rapporto che descriva tutti i rischi associati e le spese rispetto alle opportunità. in altre parole, sai come dovrebbe essere fatto, quindi dovrai provarlo tramite un rapporto abbastanza completo che descrive in dettaglio ciò che hai detto sopra. non un pensiero felice, ma uno che sarà effettivamente una consegna di prodotti in quanto tale, in quanto il tipo di analisi che devi fare è un prodotto che molte aziende creerebbero un budget per.

Spero che questo aiuti

jim

Answer 5

il miglior articolo che ho visto su questo argomento viene da Joel, ed è here.

Se vi ricordate il browser Netscape, questo è stato uno dei browser più popolari alla fine degli anni 1990, ma come sottolinea Joel per quanto riguarda la caduta di Netscape:

Lo hanno fatto, rendendo il singolo peggiore strategica errore che qualsiasi software azienda può fare:

Hanno deciso di riscrivere il codice da zero.

La cosa da ricordare è che non importa quanto sia pericoloso quel codice, non importa quanto di un naufragio sia, ci sono parti di esso che sono probabilmente molto importanti per l'applicazione. Se lo scarti e parti da sratch, rischi di perdere funzionalità critiche e la tua applicazione potrebbe essere un'altra storia netscape.

Non è mai piacevole passare e capire quale codice di qualcun altro sta facendo, ma di solito è il modo più sicuro e più sicuro per fare una riscrittura nel modo giusto.

Quindi ridimensionare, migliorare, consolidare, aggiornare a nuove tecnologie come ASP.NET, eliminare il codice morto, ecc. Ma assicurarsi di ricordare di imparare dalle lezioni degli sviluppatori di netscape, ovvero, non gettare via il codice esistente.

Come qualcuno ha detto una volta, è sempre meno doloroso imparare dagli errori degli altri che dai propri errori.

Buona fortuna!

Answer 6

Mi sono trovato in situazioni simili ma probabilmente mai niente di così brutto. Il mio miglior consiglio è di fare qualcosa che sarà visibile subito. Quindi prenditi il ​​tempo necessario per fare un po 'del lavoro dietro le quinte. Suggerisco anche qualsiasi pagina che aggiorni con il nuovo codice che aggiorni anche con un nuovo look - anche se è solo un po 'più piccolo che metterà a posto il vecchio e il nuovo. Speriamo che questo porti avanti la gestione con i tuoi piani per portare tutto aggiornato. In bocca al lupo!

Answer 7

consiglio vivamente di leggere "Working effectively with legacy code"

riscritture incrementali e passo-passo de-crufting è la soluzione migliore, se possibile. Per quanto noi (come tecnici) ameremmo gli strumenti e sistemassimo la palla-o-fango, la maggior parte delle volte non riuscirai a smettere di offrire funzionalità di business per mesi e mesi - se lo fai perdi la buona volontà di gli utenti finali per il nuovo sistema prima ancora che sia completato.

http://ecx.images-amazon.com/images/I/51TG9F1B8AL._SL500_AA300_.jpg http://ecx.images-amazon.com/images/I/51TG9F1B8AL._SL500_AA300_.jpg

Answer 8

Brian - le mie simpatie, sembra che tu hai preso su uno dei miei vecchi clienti. Scusa per il casino che ti ho lasciato, ma ho provato a sistemare le cose prima che il cliente finisse i soldi.

Seriamente, ho avuto un client con più di 25 app in un simile pasticcio - dopo due anni, circa 1/2 di loro sono stati esaminati e i primi 5 ripuliti un po '.

Non parli delle dimensioni della squadra, ma superare la riluttanza a cambiare le cose può rendere impossibile fare qualsiasi cosa. Se è così, scappa - non c'è niente di più frustrante di riscrivere qualcosa solo per scoprire che i tuoi altri sviluppatori stanno sabotando i tuoi sforzi non essendo a bordo.

Supponendo di avere supporto, puoi cercare di risolverlo da una prospettiva dall'alto verso il basso o dal basso verso l'alto.

La prima cosa da fare è mettere una struttura al suo posto: portare tutto il casino in un sistema di versione, quindi almeno è possibile tenere traccia di ciò che si sta facendo e tornare indietro se necessario. Impostare un ambiente di test separato in modo da poter provare le cose senza influire sullo sviluppo continuo e sulla capacità di supportare il sistema.

Se ti stai avvicinando da una prospettiva top-down, ti consigliamo di iniziare ripulendo gli elementi dell'interfaccia utente: elimina tutto il CSS incorporato, ripulisci & razionalizzandolo. Inventa le pagine, le dipendenze, ecc. (Questo da solo potrebbe richiedere del tempo, specialmente con ASP classico).Identifica blocchi di codice ripetuti e considera di spostarli in controlli utente condivisi. Verifica se è possibile mappare i componenti dell'interfaccia utente in elementi del database.

Analizzare i registri di accesso per trovare ciò che viene utilizzato e, auspicabilmente, identificare il codice che non è più necessario. Probabilmente troverai anche una serie di errori - questi possono essere davvero molto utili per capire il sistema. Probabilmente scoprirai che un piccolo sottoinsieme dell'applicazione viene usato più spesso - questo è un buon posto per cercare una vittoria più facile e anticipata.

Creare un set di piccoli file CSS puliti e creare alcune pagine master che è possibile utilizzare per standardizzare il look & feel. Dovrai riscrivere le pagine asp, ma potresti essere in grado di aggiornare le pagine webform per usare più facilmente le nuove pagine master.

L'obiettivo di questo approccio non è quello di sistemare molto, ma di comprendere la struttura e imporre un'organizzazione su di esso. La tecnologia low-tech può aiutare: stampare ogni pagina delle applicazioni più comuni e fissarle su un muro. Vedere tutto in questo modo può essere di grande aiuto.

L'approccio bottom-up inizia dal db: inventario di tutte le tabelle & stored proc. Vedi se riesci a capire dove viene usato ogni &. Potresti pensare che qualcosa non sia usato, ma in realtà l'unico modo per sapere con certezza è rimuovere l'oggetto dal database (o rinominarlo) e fare test. (Sì, ho visto il codice che crea dinamicamente nomi di tabelle basati sull'input dell'utente - nessuno strumento di analisi può aiutarti.)

Una volta che hai un'idea migliore delle dipendenze tra le diverse parti, puoi iniziare pianificando come fare gradualmente le correzioni. Se è possibile isolare diversi sottosistemi, prendere in considerazione l'esecuzione di una migrazione a un nuovo schema/gruppo di tabelle e creare un livello di accesso ai dati appropriato. Puoi prendere in considerazione l'idea di incorporare i test di unità a questo punto, ma onestamente avrai abbastanza problemi a portata di mano, e questo potrebbe rivelarsi un rompicapo per chi non ha familiarità con esso - impara a camminare prima di provare a volare.

Se non è possibile separare completamente le parti, prendere in considerazione l'esecuzione della migrazione, ma vedere se è possibile inserire viste o nuovi frammenti come livello facciata fino a quando il codice può essere riscritto.

Esistono numerosi libri che trattano i sistemi legacy di reingegnerizzazione, non sono sicuro che qualcuno di loro si occuperà di questa situazione, ma non potrebbe fare male rivedere la letteratura per ulteriori suggerimenti.

Buona fortuna, e non dimenticare di mantenere il curriculum aggiornato!

Answer 9

Affrontare solo la parte database di questo, ecco un libro che wil lhelp fuori: http://www.amazon.com/Refactoring-Databases-Evolutionary-Database-Design/dp/0321293533/ref=sr_1_1?ie=UTF8&s=books&qid=1268158669&sr=8-1

È necessario impostare cosa correttamente per il refactoring di un database e questo libro è inestimabile.

Esistono anche strumenti che possono aiutarti a trovare le query meno efficaci, a cominciare da quelle. Se riesci a ottenere una grande vittoria in termini di prestazioni su qualcosa che infastidisce tutti, allora ti darà più leva per continuare a correggere gli altri problemi.

Si potrebbe anche guardare un libro sull'ottimizzazione delle prestazioni specifico per il back-end di base dati che si ha. Ci sono molti problemi relativi alla perfornace che riguardano sia la progettazione del database che il design delle query, sapendo come risolverli può aiutarti in maniera immersiva mentre rifatti questo problema.

so che è forte la tentazione di buttare fuori e ricominciare di nuovo, ma si sarà l'introduzione di importanti nuovi bug in questo modo, prendendo una quantità enorme di tempo, mentre gli utenti vedono alcun miglioramento e forse manca un po 'molto importante affari regole che devono essere applicate. Mentre cambiare incessantemente e refactoring sembra essere più difficile in un caso così cattivo, è davvero la scelta migliore.

Si potrebbe parlare con gli utenti e scoprire quali sono i peggiori problemi del sistema, questo è un punto di partenza dopo aver reso gli utenti più felici è parte di ciò che siete lì per.

Assicurati di documentare i miglioramenti delle prestazioni e altre modifiche per il tuo curriculum. Pensa a quanto meglio guarderà al tuo prossimo potenziale datore di lavoro quando riuscirai a fornire dati reali sul miglioramento delle prestazioni. Accompagnare le figure allegate alle figure che mostrano quanto riesci a ottenere è raro nei curricula, questo lavoro può davvero farti risaltare in futuro come qualcuno che fa le cose.