Migrazione da ASP Classic a .NET e mitigazione del dolore

Question

Stiamo riprogettando la sezione rivolta al cliente del nostro sito in .NET 3.5.Finora è andato tutto bene, stiamo utilizzando lo stesso flusso di lavoro e le stesse procedure memorizzate, per la maggior parte, i cambiamenti più grandi sono l'interfaccia utente, l'ORM (dai dizionari a LINQ) e ovviamente la lingua.La maggior parte delle pagine fino a questo punto sono state banali, ma ora stiamo lavorando sulle pagine del flusso di lavoro più pesanti.

La pagina principale della nostra sezione di accettazione dell'offerta è di 1500 righe, di cui circa il 90% è ASP, con probabilmente altre 1000 righe in chiamate di funzione a include.Penso che anche le 1500 linee siano un po' ingannevoli dato che stiamo lavorando con gemme come questa

function GetDealText(sUSCurASCII, sUSCurName, sTemplateOptionID, sSellerCompany, sOfferAmount, sSellerPremPercent, sTotalOfferToSeller, sSellerPremium, sMode, sSellerCurASCII, sSellerCurName, sTotalOfferToSeller_SellerCurr, sOfferAmount_SellerCurr, sSellerPremium_SellerCurr, sConditions, sListID,  sDescription, sSKU, sInv_tag, sFasc_loc, sSerialNoandModel, sQTY, iLoopCount, iBidCount, sHTMLConditions, sBidStatus, sBidID, byRef bAlreadyAccepted, sFasc_Address1, sFasc_City, sFasc_State_id, sFasc_Country_id, sFasc_Company_name, sListingCustID, sAskPrice_SellerCurr, sMinPrice_SellerCurr, sListingCur, sOrigLocation)

La pratica standard che ho utilizzato finora è quella di passare circa un'ora a leggere l'app sia per familiarizzare con essa, ma anche per eliminare il codice commentato/deprecato.Quindi lavorare in modo approfondito.Inizierò dall'alto e copierò un segmento di codice nel file aspx.cs file e inizio a riscrivere, effettuando evidenti refactoring man mano che procedo soprattutto per sfruttare il nostro ORM.Se ricevo una chiamata di funzione che non abbiamo, scriverò la definizione.

Dopo aver codificato tutto, eseguirò alcuni passaggi di refactoring/test.Mi chiedo solo se qualcuno ha qualche consiglio su come rendere questo processo un po' più semplice/più efficiente.

Answer 1

Credimi, lo so esattamente da dove vieni..Attualmente sto migrando un'app di grandi dimensioni da ASP classico a .NET.E sto ancora imparando ASP.NET!:S (sì, sono terrorizzato!).

Le cose principali che ho tenuto in mente sono queste:

• Non mi smarrisco pure lontano dal progetto attuale (cioèno massiccio "eliminiamo TUTTO questo e rendiamo ASP.NET magico!) a causa della quantità incredibilmente elevata di accoppiamento che ASP classico tende ad avere, questo sarebbe molto pericoloso.Naturalmente, se sei sicuro, riempi gli stivali :) Questo può sempre essere rifattorizzato in seguito.
• Esegui il backup di tutto con test, test e ancora test!Sto davvero cercando di entrare in TDD, ma è molto difficile testare le app esistenti, quindi ogni volta che rimuovo un pezzo di classico e lo sostituisco con .NET, mi assicuro di avere a disposizione il maggior numero possibile di test di via libera.
• Fai molte ricerche, ci sono alcuni IMPORTANTI cambiamenti tra la versione classica e .NET e talvolta ciò che può essere molte righe di codice e include in classico può essere ottenuto in poche righe di codice, pensare prima di codificare..L'ho imparato nel modo più duro, diverse volte: D

È molto simile a giocare Jenga con il tuo codice :)

Buona fortuna con il progetto, per qualsiasi altra domanda, chiedi pure :)

Answer 2

Dopo aver codificato tutto, eseguirò alcuni passaggi di refactoring/test.Mi chiedo solo se qualcuno ha qualche consiglio su come rendere questo processo un po' più semplice/più efficiente.

Normalmente non sono un fan di TDD, ma nel caso del refactoring è davvero la strada da percorrere.

Scrivi prima alcuni test per verificare cosa sta effettivamente facendo la parte che stai guardando.Quindi refactoring.Questo è MOLTO più affidabile del semplice "sembra che funzioni ancora".

L'altro enorme vantaggio di questo è che quando stai effettuando il refactoring di qualcosa che si trova più in basso nella pagina, o in una libreria condivisa o qualcosa del genere, puoi semplicemente rieseguire i test, invece di scoprire nel modo più duro che un file apparentemente non correlato modifica era effettivamente correlati

Answer 3

Stai passando dall'ASP classico all'ASP 3.5 senza solo riscrivere?Skillz.Ho avuto a che fare con alcuni ASP @work legacy e penso che sia semplicemente più semplice analizzarli e riscriverli.

Answer 4

Una pagina ASP da 1500 righe?Con molte chiamate per includere file?Non dirmelo: le funzioni non hanno alcuna convenzione di denominazione che ti dica quale file di inclusione ha la sua implementazione...Ciò riporta alla memoria i ricordi (rabbrividire)...

Mi sembra che tu abbia un approccio piuttosto solido: non sono sicuro che esista un modo magico per mitigare il tuo dolore.Dopo il tuo sforzo di conversione, l'architettura della tua app sarà ancora disordinata e con un'interfaccia utente pesante (ad es.flussi di lavoro in esecuzione code-behind) e probabilmente sarà ancora abbastanza doloroso da mantenere, ma il refactoring che stai eseguendo dovrebbe sicuramente aiutare.

Spero che tu abbia soppesato l'aggiornamento che stai facendo rispetto alla semplice riscrittura da zero, a patto che tu non intenda estendere troppo l'app e non sei il principale responsabile della manutenzione dell'app, aggiornando un'app complessa basata sul flusso di lavoro come te stanno facendo potrebbe essere più economico e una scelta migliore rispetto a riscriverlo da zero.ASP.NET dovrebbe offrire migliori opportunità per migliorare le prestazioni e la scalabilità, almeno, rispetto all'ASP classico.Dalla tua domanda immagino che sia comunque troppo tardi per quella discussione.

Buona fortuna!

Answer 5

Sembra che tu abbia una buona padronanza delle cose.Ho visto molte persone provare a fare una traslitterazione in linea retta, include e tutto, e semplicemente non funziona.È necessario avere una buona conoscenza di come ASP.Net vuole funzionare, perché lo è tanto diverso dall'ASP classico e sembra che tu ce l'abbia.

Per file più grandi, proverei prima a ottenere una visualizzazione di livello superiore.Ad esempio, una cosa che ho notato è che ASP classico era pessimo riguardo alle chiamate di funzione.Leggeresti del codice e troveresti una chiamata a una funzione senza alcuna idea di dove potrebbe essere implementata.Di conseguenza, il codice ASP classico tendeva ad avere funzioni e script lunghi per evitare quei brutti salti.Ricordo di aver visto una funzione che stampava fino a 40 pagine!Analizzare direttamente così tanto codice non è divertente.

ASP.Net rende più semplice seguire le chiamate di funzione, quindi potresti iniziare suddividendo i blocchi di codice più grandi in diverse funzioni più piccole.

Answer 6

Non dirmi: le funzioni non hanno alcuna convenzione di denominazione che ti dice che include il file ha la loro implementazione ...Ciò riporta ricordi (brivido) ...

Come hai indovinato?;)

Spero che tu abbia pesato l'aggiornamento che stai facendo contro il solo riscrittura da zero-purché non intenda estendere troppo l'app e non sei principalmente responsabile del mantenimento dell'app, aggiornando un'app complessa basata sul flusso di lavoro come te stanno facendo potrebbe essere più economico e una scelta migliore rispetto a riscriverlo da zero.ASP.NET dovrebbe offrirti migliori opportunità per migliorare le prestazioni e la scalabilità, almeno, rispetto al classico ASP.Dalla tua domanda immagino che sia comunque troppo tardi nel processo per quella discussione.

Questo era qualcosa di cui abbiamo parlato.In base ai tempi (cercare di battere il sito di un concorrente per il lancio) e alle risorse (sostanzialmente due sviluppatori) era logico non bombardare il sito dall'orbita.In realtà le cose sono andate molto meglio di quanto mi aspettassi.Eravamo consapevoli già in fase di progettazione che questo codice ci avrebbe dato i maggiori problemi.Dovreste vedere lo storico delle revisioni delle pagine ASP classiche coinvolte, è un bagno di sangue.

Per file più grandi, proverei prima a ottenere una vista di livello superiore.Ad esempio, una cosa che ho notato è che l'ASP classico era orribile per le chiamate della funzione.Leggeresti un po 'di codice e troveresti una chiamata a una funzione senza alcun indizio su dove potrebbe essere implementato.Di conseguenza, il codice ASP classico tendeva ad avere lunghe funzioni e script per evitare quei cattivi salti.Ricordo di aver visto una funzione stampata a 40 pagine!L'analisi dritto attraverso questo codice non è divertente.

In realtà ho avuto questo dispiacere per un bel po' di lavorare con il codice legacy, quindi ho una discreta conoscenza di alto livello del sistema.Hai ragione riguardo alla lunghezza della funzione, ci sono alcune routine (la maggior parte delle quali ho rifattorizzato in routine molto più piccole) che sono 3-4 volte più lunghe di qualsiasi pagina aspx/classe helper/ORM sul nuovo sito.

Answer 7

Una volta mi sono imbattuto in un'app .Net trasferita da ASP.Le pagine .aspx erano completamente vuote.Per eseguire il rendering dell'interfaccia utente, gli sviluppatori hanno utilizzato StringBuilders nel code-behind e quindi hanno eseguito un Response.write.Questo sarebbe il modo sbagliato di farlo!

Answer 8

Una volta mi sono imbattuto in un'app .Net trasferita da ASP.Le pagine .aspx erano completamente vuote.Per eseguire il rendering dell'interfaccia utente, gli sviluppatori hanno utilizzato StringBuilders nel code-behind e quindi hanno eseguito un Response.write.Questo sarebbe il modo sbagliato di farlo!

L'ho visto fare nell'altro modo, il codice dietro la pagina era vuoto, ad eccezione della dichiarazione dei globali, quindi VBScript è stato lasciato in ASPX.