Qualsiasi formula per decidere se utilizzare uno script (ad es. bash) o codificare un'app (LAMP)?

Question

Qualsiasi formula per decidere se utilizzare uno script (ad es. bash) o codificare un'app (LAMP)?

#1 da (1 voti)
#2 da (0 voti)

1

Abbiamo alcune app diverse X, Y, X di terze parti diverse e vogliamo trasferire i dati in un'app centralizzata C, quindi quando gli utenti immettono i dati in C possono precompilare moduli con dati correlati. Se inseriscono un ID cliente dall'app X in C, riceveranno informazioni sull'indirizzo cliente, indirizzo, ecc. Da X, compilando moduli in C.

Un'idea, avere uno script di cron job per ogni app X, Y, Z ..., che interroga i loro database e produce un file / urson standard json: X-related-info.json, Y-related-info. json ecc. ogni giorno. L'app C può ritirare su richiesta. Questa informazione cambia raramente ed è un numero limitato di record. Puoi eseguire il cron ogni minuto senza problemi.

Costo per scrivere script bash personalizzati / cron + test + documenti = 60 minuti (per ogni X, Y, Z ... app).

[ X ] --> bash script --> [ C ]

Un'altra idea è quella di creare un'app gateway GW, che farebbe una query in tempo reale a X, Y, Z e presenterebbe similmente un url json all'app C. Avrebbe una GUI per aggiungere app di terze parti che si desidera ottenere dati da Tuttavia, è necessario scrivere codice personalizzato per ogni X, Y, Z poiché sono app di terze parti diverse con design di database diversi.

Quindi il costo per fare GW app + test + documentazione = 1 settimana, + costo per scrivere codice personalizzato + test = 60 minuti (per ogni X, Y, Z ... app)

[ X ] --> custom code --> GW app --> [ C ]

La mia conclusione è che dal momento che devi comunque creare codice personalizzato per ogni X, Y, Z, per l'app GW, basta usare lo script cron e bash - non c'è bisogno dell'app GW. Ho sentito che è abbastanza chiaro. Sono riluttante a realizzare un'altra app perché abbiamo un sovraccarico di risorse, test e documentazione a basso costo e ci occupiamo di futuri bug / problemi di manutenzione di un'altra app e siamo in ritardo su altri aspetti. Ma un responsabile senior dice no, dovremmo creare l'app GW perché è più flessibile e a prova di futuro. Andato oltre la sua spiegazione di nuovo, abbiamo ancora bisogno di codice personalizzato per X, Y, Z ... app. Non penso che la flessibilità / l'impermeabilità al futuro battano i costi effettivi del tempo.

project-management design-patterns

posta user95437 29.11.2017 - 15:18

fonte

2 risposte

Leggi altre domande sui tag project-management design-patterns

Modo corretto per tracciare l'evoluzione del ranking di alcuni record db Configurare il flusso di lavoro del gestore dell'integrazione

score 1 · Answer 1

Sembra che tu abbia sostanzialmente risposto alla tua stessa domanda.

Per quanto riguarda la flessibilità, la domanda è quante estensioni si prevede di avere nel prossimo futuro. Offuscano il costo dello sviluppo delle app in anticipo?

Con le stime che hai fornito, sarebbe, naturalmente, prendere una quantità infinita di estensioni per ammortizzare i costi, perché non sembra che tu stia guadagnando nulla: in entrambi i casi, hai bisogno di 60 minuti per app.

Ma dal momento che l'investimento è piccolo in ogni caso, e a condizione che non ti aspetti una nuova app nelle prossime settimane, perché non suggerire l'approccio semplice come un prototipo che puoi sempre sostituire in seguito.

score 0 · Answer 2

In base alla tua domanda e al tuo commento, proporrei un approccio diverso:

Another idea is to create a gateway app GW, that would do a real-time query to X,Y,Z and similarly present a json url to app C. It would have a GUI to add third party apps you want to get data from. However, you would still need to write custom code for each X, Y, Z as they are apps by different 3rd parties with different database designs.

Cost to write custom bash script/cron + tests + docs = 60 mins (for each X,Y,Z... app).

So cost to make GW app + tests + documentation = 1 week, + cost to write custom code + tests = 60 mins (for each X,Y,Z... app)

Secondo me, GW Gui è totalmente privo di senso. Questa GUI renderebbe l'applicazione C altamente personalizzabile, cosa che non lo è (perché hai ancora bisogno del codice per fare le nuove query).

Pertanto, suggerisco un approccio più simile a un plug-in . Per un'app aggiuntiva di terze parti, devi solo implementare un nuovo "codice personalizzato" (una sorta di codice di plugin per C), che hai detto impiega lo stesso tempo del copione bash. Suggerisco codice invece di bash, perché puoi beneficiare delle funzionalità di OOP e fornire alcune interfacce per i tuoi plug-in per aderire ed essere in grado di fornire dati di app di terze parti aggiuntive.

Riassumendo: definisci un'interfaccia "dati di terze parti" nella tua app C e crea un nuovo codice che implementa questa interfaccia per ogni nuova app aggiuntiva.