Il refactoring & # 8220; include il file hell & # 8221;

StackOverflow https://stackoverflow.com/questions/143745

Domanda

Una cosa che ha davvero reso la vita difficile nell'accelerare la base di codice in un progetto ASP classico è che la situazione del file include è un po 'un casino. A volte trovo che la funzione che cercavo fosse inclusa in un file include totalmente non correlato. Qualcuno ha qualche consiglio su come riformattare questo in modo tale da poter dire più facilmente dove si trova una funzione se è necessario trovarla?

MODIFICA: Una cosa che ho dimenticato di chiedere: vbscript ha qualche tipo di meccanismo per impedire che un file venga incluso due volte? Sorta come # ifndef è di C?

È stato utile?

Soluzione

Ci sono alcune cose di base che puoi fare quando acquisisci un'applicazione ASP classica, ma probabilmente finirai per pentirti di averle fatte.

  1. Elimina file di inclusione duplicati . Ogni app ASP classica che abbia mai visto ha avuto 5 "login.asp" pagine e 7 "datepicker.js" file e così via. Cerca e rimuovi tutti i duplicati, quindi modifica i riferimenti nel resto dell'app, se necessario. Fai attenzione a fare un controllo diff su ogni file mentre lo rimuovi - spesso i file duplicati presentano lievi differenze perché l'autore originale lo ha copiato e quindi modificato solo la copia. Questa è un'ottima cosa per Evolution, ma non tanto per il codice.
  2. Crea una struttura di cartelle razionale e sposta tutti i file in essa. Questo è ovvio, ma è quello di cui ti pentirai di più. Se i collegamenti nell'applicazione sono relativi o assoluti, dovrai modificarne la maggior parte.
  3. Combina tutti i tuoi file include in un unico file grande . È quindi possibile riordinare logicamente tutte le funzioni e suddividerle in file separati e con un nome ragionevole. Dovrai quindi passare attraverso l'app pagina per pagina e capire quali devono essere le dichiarazioni di inclusione su ogni pagina (o attenersi a un unico file e includerlo solo su ogni pagina - Non ricordo se o no questa è una buona idea in ASP). Non riesco a comprendere il livello di dolore coinvolto qui, e questo presuppone che i file di inclusione esistenti non facciano un uso pesante dei globi con lo stesso nome.

Non farei nulla di tutto ciò. Per parafrasare Steve Yegge (credo), " non c'è niente di sbagliato in un'applicazione ASP classica che non può essere risolta con una riscrittura totale " ;. Sono molto serio al riguardo - non credo che ci sia una perdita di tempo maggiore di un programmatore in questo mondo rispetto alla manutenzione di un'app ASP, e il problema peggiora man mano che ASP diventa sempre più obsoleto.

Altri suggerimenti

@ MusiGenisis l'elenco dei punti elenco è un buon consiglio da seguire ma non sono d'accordo con -

" Non farei nulla di tutto ciò. Per parafrasare Steve Yegge (credo), "non c'è niente di sbagliato in un'applicazione ASP classica che non può essere risolta con una riscrittura totale". Sono molto serio al riguardo - non penso che in questo mondo ci sia una perdita di tempo maggiore di un programmatore rispetto alla manutenzione di un'app ASP, e il problema peggiora man mano che ASP diventa sempre più obsoleto. & Quot;

Tutto molto bene, ma se si tratta di un'app legacy considerevole che esegue riscritture complete spesso non è possibile a causa della mancanza di tempo / risorse per gli sviluppatori.

Abbiamo un'app ASP classica abbastanza grande che negli anni ha sviluppato braccia e gambe, non è carina ma soddisfa le esigenze aziendali. Non abbiamo tempo da dedicare ai prossimi sei mesi per una riscrittura completa, sarebbe bello, ma semplicemente impossibile. Il nostro approccio è -

  1. Dove sono richieste nuove funzionalità, è implementato in ASP.NET. Questo accade il 95% delle volte. I casi limite del 5% di solito sono che ci sono molti punti in cui il nuovo codice app tocca la vecchia app richiedendoci di fare un sacco di rielaborazioni ASP classiche potenzialmente rendendo l'app più fragile.

  2. Laddove si verifica un cambiamento nella funzionalità, valutiamo se possiamo eseguire il refactoring su ASP.NET con un impatto minimo. Se ciò non è possibile, implementeremo la modifica dell'ASP classico e riordineremo il codice esistente mentre procediamo, ad es. la semplificazione include l'annidamento dei file, la sostituzione di javascript con altro codice compatibile con più browser, questo genere di cose.

In risposta alla tua domanda su # ifndef's, non c'è un equivalente che temo.

  1. Usa un file per le intestazioni globali e include (chiamiamolo t-head.asp). Questo file è incluso in tutti i file asp.
  2. Utilizza un solo file per rendere visiva l'intestazione globale del sito (loghi, menu, ecc.) e includerla subito dietro. Lascialo chiamare t-begin.asp
  3. Utilizza un solo file per rendere il piè di pagina globale visivo del sito (copyright, analisi di google, ecc.) e chiudere tutte le div o le tabelle aperte in t-begin.asp. Chiamiamo questo file t-end.asp
  4. Utilizzare una cartella per inserire i file di business logic, chiamati BUS. I file in questa cartella non possono avere inclusioni. Ogni funzione all'interno del file deve essere preceduta dal nome dell'unità logica (IE: tutte le funzioni in products.asp devono iniziare con product_ *)
  5. Utilizzare una cartella per inserire un codice UI riutilizzato chiamato UI. I file in questa cartella non possono avere inclusioni.

Esempio: 

<%@  Language=VBScript %>
<% Option Explicit %>
<% Response.Buffer = true%>
<html>
<head>
<!--#include file="../general/t-head.asp"-->
<!--#include file="../bus/product.asp"-->
<title>Products page</title>
</head>
<body>
<!--#include file="../general/t-begin.asp"-->

   <% 'all your code  %>

<!--#include file="../general/t-end.asp"--> 
</body>
</html>

Wow. Mi sorprende costantemente quante persone hanno odio per ASP. In buone mani è un linguaggio perfettamente capace per la progettazione di applicazioni web.

Tuttavia, ammetterò che il modo in cui i file di inclusione sono gestiti in ASP può essere un po 'un mal di testa - perché (a seconda di come li usi) devono essere caricati e analizzati anche se non stai usando la metà le funzioni contenute all'interno.

Tendo ad avere un file include ( initialise.asp o alcuni di questi) che a sua volta include collegamenti a diverse librerie di funzioni ( lib_http.asp , lib_mssql. asp o simili) e tutte le funzioni della libreria sono autonome, quindi non è necessario incrociare le variabili. Eventuali var globali sono dichiarati e impostati nel file principale. Questo significa che posso usare una funzione ovunque, in qualsiasi momento e non preoccuparmi di dove è stata definita, è lì solo per l'uso. E gli IDE come Visual Studio e Primalscript hanno la possibilità di "passare alla definizione" quando trovi una chiamata a una funzione che non riconosci.

Quindi, qualsiasi inclusione specifica dello script viene inclusa nello script dopo la chiamata a questo file di inclusione principale.

Ammetto che si tratta di un approccio affamato di memoria poiché tutte le funzioni di tutte le librerie sono compilate per ogni chiamata di script, quindi il metodo deve essere perfezionato per ogni sito sviluppato - decidi cosa chiamare tramite il master e cosa è più specifico della pagina. Sarebbe bello poter caricare solo ciò di cui hai bisogno, ma questo è l'approccio DLL e non è disponibile per la maggior parte degli sviluppi del mondo reale, e dovresti anche valutare il costo del processore per la compilazione di piccoli script vs caricamento dei componenti.

Una struttura di directory concisa è necessaria e facile da sviluppare, ma può essere una seccatura passare in rassegna tutto il codice in un sito esistente e modificare eventuali collegamenti o chiamate mappath. Inoltre, tieni presente che alcuni amministratori IIS non consentono il metodo '.. \' per attraversare le directory tramite VBScript, quindi tutti i riferimenti ai file devono essere percorsi assoluti.

Penso che dovresti considerare di spostare il tuo codice da ASP VBScript a DLL COM di Visual Basic. ciò faciliterà il fatto che tu abbia troppe inclusioni.

Non conosco un modo per prevenire una doppia inclusione, oltre a ricevere un messaggio di errore. Stai vedendo inclusioni posizionate in tutta la pagina, il che le rende difficili da individuare?

A parte questo, stai lavorando con una copia del codice e del database su un server di sviluppo? Dalla mia esperienza, la prima cosa da fare è separarti dal sito dal vivo al più presto. Sebbene inizialmente una seccatura, ti darà la libertà di apportare modifiche senza rovinare il sito live. È facile apportare un piccolo cambiamento in un include e BAM! l'intero sito non funziona.

Ho lavorato su alcuni progetti come hai descritto e utilizzato le seguenti strategie:

Riscrittura completa: perfetta quando c'è tempo / denaro, ma di solito ricevo la chiamata quando qualcosa è andato storto e i risultati sono necessari al più presto.

Progetti più piccoli: apro tutto nell'IDE e inizio a cercare tutti i file di progetto per le funzioni / sub, al fine di acquisire una conoscenza della logica di inclusione. Praticamente ogni volta, tutto è sparso ovunque, quindi inizio a ricostruire le inclusioni organizzate dalla logica aziendale. Ho anche incontrato codice incorporato (codice non elaborato, non sottotitoli o funzioni) inserito in un'inclusione, quindi di solito torno indietro il codice nella pagina per il refactoring in seguito.

Progetti più grandi - Userò del codice che ho in giro per analizzare le inclusioni per le linee con intestazioni sub / function e scaricarle in un file di testo per creare un elenco di quali routine sono e fare riferimento a quello. Questo è utile quando hai un sacco di inclusioni su ogni pagina e non riesci a trovare la base del codice.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top