Best practice per il refactoring dell'ASP classico?

Question

Devo fare uno sviluppo significativo in un sistema ASP grande, vecchio e pieno di spaghetti.Sono stato lontano da ASP per molto tempo, concentrando le mie energie sullo sviluppo di Rails.

Un passo fondamentale che ho intrapreso è stato quello di rifattorizzare le pagine in sottotitoli e funzioni con nomi significativi, in modo che almeno sia facile capire all'inizio del file cosa sta succedendo generalmente.

Esiste un framework MVC utile per ASP?O una best practice su come eliminare almeno la logica aziendale dalle visualizzazioni?(Ricordo di aver fatto molti include in passato: è ancora così che si fa?)

Mi piacerebbe fare anche dei test unitari per la logica aziendale, ma forse sto chiedendo troppo?

Aggiornamento:

Ci sono più di 200 script ASP nel progetto, lunghi alcune migliaia di righe ;) UGH!

Potremmo optare per la "grande riscrittura" ma fino ad allora, quando devo cambiare pagina, voglio dedicare un po' di tempo in più a ripulire gli spaghetti.

Answer 1

Ipotesi

La documentazione per il sistema ASP classico è piuttosto scarna.

La direzione non sta cercando una riscrittura.

Dato che hai eseguito Ruby on Rails, il tuo ASP.NET (VB/C#) è nella migliore delle ipotesi percorribile.

La mia esperienza

Anch'io ho ereditato un classico sistema ASP che è stato messo insieme, volenti o nolenti, da tipi ex excel-vba.C'erano un sacco di queste cose <font size=3>crap</font> (e talvolta tag di chiusura mancanti;Argggh!).Nel corso di 2 anni e mezzo ho aggiunto un sistema di sicurezza, una libreria comune, CSS+XHTML e sono riuscito a forzare la cosa a convalidare xhtml1.1 (senza il tipo MIME corretto, sfortunatamente) e ho creato un sistema di reporting abbastanza robusto e ajaxy che è stato utilizzato quotidianamente da 80 utenti.

Ho usato jEdit, con cTags (come menzionato da inceppamenti sopra) e un sacco di altri plugin.

Il mio consiglioProva a creare un file di inclusione principale da cui importare tutto il materiale comunemente utilizzato.Cose come login/logout, accesso al database, servizi web, librerie javascript, ecc.

Usa le lezioni.Sono ultra-primitivi (nessuna eredità) ma come ha detto Jamting, possono essere convenienti.

Rientra correttamente gli script.

Commento

Scrivere un documento di architettura esterna.Personalmente utilizzo LyX, perché produrre un PDF ben formattato è insensato, ma puoi usare quello che preferisci.Se usi un wiki, installa il componente aggiuntivo graphviz e usalo.È semplicissimo creare diagrammi rapidi che possono essere facilmente modificati.

Poiché non ho idea di quanto sostanziali debbano essere i miglioramenti, suggerisco di avere un buon documento di architettura di livello medio-alto che sarà molto utile nella pianificazione dei miglioramenti.

Nei test delle unità di logica aziendale, l'unica cosa che ho scoperto che funziona è la configurazione di un ascoltatore xml-rpc in asp che importa la libreria principale ed espone le funzioni (non le subroutine però) in uno qualsiasi dei sub-include della libreria principale, quindi costruire, separatamente, un sistema di test unitario in un linguaggio con un supporto migliore per le cose che chiamano le funzioni ASP tramite xml-rpc.Uso Python, ma penso che Ruby dovrebbe fare il trucco.(Ha senso?).La cosa bella è che la persona che scrive la parte unit-test del software non ha bisogno nemmeno di guardare il codice ASP, purché abbia descrizioni decenti delle funzioni da chiamare, in modo che possa essere qualcuno accanto a te.

C'è un progetto chiamato aspunit su sourceforge ma l'ultima versione è stata nel 2004 ed è contrassegnata come inattiva.Non l'ho mai usato ma è puro vbscript.Uno sguardo superficiale al codice mi dice che sembra che gli autori sapessero cosa stavano facendo.

Infine, se hai bisogno di aiuto, ho una certa disponibilità a svolgere lavori di telelavoro a contratto (forse un massimo di 8 ore settimanali).Segui il percorso del collegamento per le informazioni di contatto.

Buona fortuna!HTH.

Answer 2

Dato che una riscrittura completa di un sistema funzionante può essere molto pericolosa posso solo darti un piccolo consiglio:Imposta tag esuberanti, ctag, sul tuo progetto.In questo modo puoi saltare alla definizione di una funzione e di un sottotitolo in modo semplice, il che penso aiuti molto.

Sulla separazione della logica dalle "visioni".VBScript supporta una sorta di OO con le classi.Tendo a scrivere classi che eseguono la logica che includo nella pagina asp che funge da "vista".Quindi collego la vista con la classe come Nome utente:<%= MioAccount.NomeUtente %>.La classe MyAccount può anche avere metodi come:MyAccount.Login() e così via.

Un po' primitivo, ma almeno puoi incapsulare del codice e nasconderlo dall'HTML.

Answer 3

Il mio consiglio sarebbe di continuare il refactoring, l'ASP classico supporta le classi, quindi dovresti essere in grado di spostare tutto tranne il codice visualizzato nei file ASP inclusi che contengono solo classi.Vedere questo articolo sui dettagli del passaggio da ASP vecchio stile ad ASP.NET

Refactoring dell'ASP

Per quanto riguarda la direzione futura, non punterei ai moduli Web ASP.NET, preferirei invece il nuovo framework MVC di Microsoft (un componente aggiuntivo di ASP.NET). Sarà molto più semplice la migrazione a questo dal classico ASP.

Answer 4

Io uso Unità ASP per testare unità alcuni dei nostri ASP classici e trovarlo utile.Potrebbe essere vecchio, ma lo è anche ASP.È semplice, ma funziona e puoi personalizzarlo o estenderlo se necessario.

Ho anche trovato Lavorare in modo efficace con il codice legacy di Michael Feathers per essere una guida utile per trovare modi per testare parte di quel vecchio codice.

I file di inclusione possono essere d'aiuto purché tu mantenga le cose semplici.Ad un certo punto ho provato a creare un'inclusione per ogni classe e non ha funzionato molto bene.Mi piace avere un paio di inclusioni principali con una logica aziendale comune e, per le pagine complicate, a volte un'inclusione con logica per ciascuna di quelle pagine.Suppongo che potresti eseguire MVC con una configurazione simile.

Answer 5

C'è qualche possibilità che tu possa passare da ASP ad ASP.Net?Oppure stai cercando di mantenerlo nel classico ASP, ma semplicemente ripulindolo.Se possibile, consiglierei di passare il più possibile a .Net.Sembra che tu stia comunque riscrivendo/riorganizzando molto codice, quindi passare a .Net potrebbe non richiedere uno sforzo aggiuntivo.

Answer 6

Presumibilmente qualcun altro ha scritto la maggior parte o tutto il sistema che stai mantenendo ora.Cerca le solite cattive abitudini (codice ripetuto, variabili con ambito troppo ampio, istruzioni if ​​nidificate, ecc.) ed esegui il refactoring come faresti con qualsiasi altro linguaggio.Tieni d'occhio gli elementi ricorrenti nello stesso file o in file diversi e astraili in funzioni.

Se il codice è stato scritto/gestito da diverse persone, potrebbero verificarsi alcuni problemi con uno stile di codifica incoerente.Trovo che riportare in linea il codice renda più semplice vedere le cose che possono essere sottoposte a refactoring.

"Lunghezza di migliaia di righe" mi fa sospettare che potrebbero esserci anche situazioni in cui sulla stessa pagina vengono visualizzati elementi vagamente correlati.Anche in questo caso è necessario astrarli in subroutine separate.

Alla fine vorrai scrivere oggetti per aiutare a incapsulare cose come la connettività del database, ma ci vorrà un po' di tempo prima che tu ci arrivi.

Answer 7

Questo è molto vecchio, ma non ho potuto resistere ad aggiungere i miei due centesimi.Se è necessario riscrivere e continuare a utilizzare ASP classico:

• usa JScript!molto più potente, ottieni l'ereditarietà e ci sono alcuni vantaggi collaterali come l'utilizzo degli stessi metodi per la convalida lato server che usi per il lato client
• puoi assolutamente fare MVC: ho scritto un framework MVC e non c'erano molte righe di codice
• puoi anche generare automaticamente le classi del tuo modello con un po' di lavoro.Ho del codice per questo che ha funzionato abbastanza bene
• assicurati di eseguire query con parametri e di restituire sempre recordset disconnessi

Answer 8

Le pratiche di gestione dei progetti di sviluppo software indicano che software come questo devono essere ritirati.

So quanto sia difficile fare la cosa giusta, ancora di più quando il manager responsabile sa un cazzo ed ha paura di tutto tranne che del modo peggiore possibile.

Ma comunque.E' necessario iniziare a lavorare sullo sviluppo di un nuovo software.È semplicemente impossibile mantenerlo per sempre, e più aspettano per ritirarlo, peggio è.

Se non disponi di un'adeguata documentazione su specifiche/requisiti (penso che nessun software ASP al mondo ce l'abbia, data l'abilità noobtry di questi programmatori), avrai bisogno sia di un gruppo di utenti che conoscano le funzionalità del software sia di un manager che sia responsabile della convalida dei requisiti.Dovrai rivedere ogni funzionalità e documentarne i requisiti.

Durante questo processo imparerai di più sul software e sulla sua attività.Una volta che hai abbastanza informazioni, puoi iniziare a svilupparne una nuova.