Analisi dei token di testo nei file di script

We have a wide variety of customers and each has different business rules. Instead of having a single compiled code base, we are considering having different templated script files for each customer.

Direi che la premessa per questo è un po 'errata. Stai cercando una sorta di codifica modulare. Questo può essere fatto anche con altre lingue. Definisci i moduli, crea una Fabbrica che serve quello che vuoi e usalo. Probabilmente è molto più semplice che provare a tentare più volte la fonte stessa.

In addition, we need to get data into the scripts. So, we are thinking we will have variable declarations in the script, and those variables will be set to some character sequence that we will treat as a token. Then with another app, we'll process the document looking for the tokens replacing them with the actual data.

Qui è dove le cose si fanno brutte.

Hai alcuni dati in alcuni file e alcuni preprocessori (fai finta che sia gnu m4 - se lo fai ritrovati seguendo questo percorso potresti anche usarne uno buono - il tag SO associato m4 ) che legge il file, identifica le macro del modello e modifica l'origine, che viene quindi distribuita al cliente.

Quindi ora hai qualcosa di simile

site = "_SITE_"
print site, "\n"

come un codice rubino e quindi un file macro

define('_SITE_','programmers.SE')

e poi lo si esegue tramite l'applicazione m4

$ m4 main.m4 main.rb

site = "programmers.SE"
print site, "\n"

Ora inizi a ricevere molte parti mobili. Devi assicurarti che ciascun file analizzi correttamente, che alcuni siti non includano qualcosa come " che sarebbe una macro valida, ma una variabile non valida (la prenderai prima che vada al sito del cliente?) .

Soprattutto, è meglio sperare che il codice non diverga. Una volta che hai qualcosa di più della semplice esecuzione di una macro contro il codice, ma sostituendo il codice diventa brutto. Devi essere molto rigoroso con le convenzioni di denominazione in modo che i valori utilizzati in una parte della classe template non entrino in collisione con gli altri ... e che non usi nemmeno il valori da una parte del modello in un altro (si trascina solo quella parte del modello senza la parte modello che imposta i dati). Ottiene solo BRUTTO .

Peggio di tutto, e la cosa che ti brucerà alla fine con questo, non puoi testare il codice che scrivi. Puoi testare il codice che viene generato (vero?), Ma non sarai in grado di testare realmente il codice che scrivi facendo ciò che dovrebbe.

Il difetto fondamentale in questo pensiero è il mix dei dati e del codice. In sostanza, il codice che stai scrivendo in questo modello sono i dati per un processore macro che sputa il nuovo codice.

Se vuoi variabili di template, leggi quelle di un file di proprietà di qualche tipo.

Archivia i dati come dati e caricali come dati. Ad esempio, memorizzarlo in un oggetto JSON e caricarlo in un oggetto con la libreria appropriata ( ruby python ).

Quindi stai semplicemente distribuendo i diversi dati ai diversi siti (con lo stesso codice base) che indicano i valori che sono diversi tra loro. Utilizzerai i valori nei dati per chiamare il metodo factory corretto (che funziona bene da solo senza modelli e può essere testato su unità).

Beh, la qualità generale è, um, non buona.

Le cose che sembrano più chiaramente sbagliate (dal momento che quasi tutto ciò che è di solito sbagliato ha il caso strano in cui ha senso) sono l'idea di dividere in più basi di codice e l'idea di passare i dati in uno script inserendo meta -guarda e poi sostituisce quelli con i dati letterali.

Il problema con più code-code è molto più serio. Probabilmente funzionerà benissimo per un breve periodo di tempo, per poi trasformarsi in un disastro in modo costante, poiché i problemi comuni a più clienti devono essere risolti eseguendo la stessa modifica in più code-base separate. Mentre si allontanano, lo stesso logico cambiamento diventerà più spesso un diverso codice cambiamento, quindi non sarà più un noioso taglia e incolla, ma sempre più come scrivere il codice più volte - con possibilità di incontrare più bug. Potresti finire per dover reinserire il codice in un unico code-base, che sarà lontano più difficile di quanto non fosse per dividerli. A quel punto, più probabilmente non lo farai, che sarà peggio.

Se in qualche modo si modifica il codice così raramente che non si raggiunge mai il punto in cui questo approccio ha un costo maggiore del vantaggio, suppongo che potrebbe avere senso. È un po 'difficile immaginare uno scenario plausibile in cui sia comunque una buona idea - forse se il codice è davvero vicino all'unicità per ogni cliente e il resto del codice è condiviso tra tutti i clienti.

Avere un sacco di comportamenti speciali su un cliente per cliente è molto comune. La solita soluzione è quella di calcolare il comportamento più comune che puoi (è qui che entra in gioco l'abilità ingegneristica, ma anche una cattiva progettazione probabilmente supererà la progettazione separata del codice). Se tutto il resto fallisce, puoi suddividere il comportamento specifico del cliente in parti logiche e avere un flag di configurazione per ogni pezzo, piuttosto che testare l'ID cliente nel codice (ad esempio, utilizzare il rilevamento delle funzioni, non lo sniffing del browser). Quindi, quando un nuovo cliente desidera alcune di quelle funzioni, non è necessario scavare nel codice per estrarre le funzionalità.

Per quanto riguarda l'idea di compilare valori in script comuni - è strano e sembra più difficile di quanto non debba esserlo, ma nel peggiore dei casi non ti rovinerà la vita. Generalmente il passaggio di variabili tramite gli argomenti della riga di comando o il loro inserimento in un file di configurazione (probabilmente un database di configurazione) è come le persone farebbero questo.

Per quanto riguarda il problema dell'arresto di un servizio - il codice interpretato può aiutare, ma hai pensato a cosa succede se i file vengono scambiati durante l'esecuzione di un processo? Se il file Q ha dipendenze su N, O e P e mentre Q sta eseguendo uno swap di aggiornamento nelle nuove versioni di N, O e P, il tuo codice funzionerà correttamente? Farai QA questo? Come pensi di farlo? Se il comportamento scorretto del programma non è un grosso problema, può essere accettabile, ma se l'errata ha gravi conseguenze, si potrebbe finire per implementare l'equivalente di abbattere un servizio che esegue un codice compilato. In primo luogo, elimina la tua motivazione originale per l'utilizzo del codice interpretato.

Modifica - Sento che dovrei menzionare il fatto che più basi di codice sono accettabili in un certo senso - i moduli liberamente accoppiati che lavorano insieme per creare un'applicazione in cui ogni modulo possa fare qualcosa di utile anche in isolamento è piuttosto O.K. Copiare lo stesso codice tra più basi di codice e lasciarle evolvere individualmente è raramente una buona idea.

I problemi che citi non hanno nulla a che fare con il codice rispettato rispetto agli script. Ha più a che fare con la progettazione del software. Se pensano che più basi di codice risolveranno i loro problemi, loro e l'organizzazione sarebbero meglio se le lasciassero andare in modo da poter trovare lavoro altrove e imparare da un professionista. La tua organizzazione dovrebbe assumere almeno una persona che possa guidare e comprendere i problemi.

È difficile per me enumerare i motivi per cui questa idea è così brutta, è un po 'come spiegare perché 2 + 2 = 4.

Se fossi al comando, a casa tua lavorerei per sviluppare un design che sia altamente coeso e liberamente accoppiato. Ci sarebbero moduli che sono stati scritti in modo tale da poter essere utilizzati da tutti i clienti. Ci sarebbero alcuni moduli che sarebbero utilizzati solo da alcuni clienti. Alcuni codici sarebbero utilizzati solo da un cliente.

Queste varie parti potrebbero essere assemblate in fase di compilazione da alcuni smart build / script di implementazione o da file di configurazione.

È bello sapere che i tuoi sensi sono corretti, tuttavia è una situazione davvero scadente in cui ti trovi. Francamente hai "pesi pesanti" che vogliono giocare alla roulette russa con 6 proiettili nella camera.

E sì, potrei inventarmi qualcosa di meglio. Ho fatto così tante volte nella mia carriera.