Qual è la differenza tra un prototipo e una soluzione a livello di produzione?

Questa domanda è puramente per l'apprendimento e per rafforzare la mia comprensione tecnica. So che non esiste una soluzione perfetta e questa domanda ha una lista infinita di soluzioni, ma penso che sia molto importante per ogni architetto capire la differenza tra una demo e un progetto live.

Ho creato molte soluzioni demo in .Net in passato. Ora sono stato assegnato a Architect e implementare una soluzione web a livello di produzione, quindi volevo chiedere - a un livello molto alto, cosa è necessario per convertire una demo in una soluzione a livello di produzione. Da quanto ho capito, ciò richiederà (oltre all'implementazione funzionale dei requisiti dei clienti):

1. Test unitari di ogni metodo
2. Garantire una copertura del codice del ~ 100%
3. Registrazione di tutte le eccezioni e possibili tagli di punti - possibile con AOP
4. Utilizzo del modello di progettazione dell'interfaccia, iniezione di dipendenza, eventualmente utilizzando un framework, ad esempio spring.net
5. Utilizzo di contatori delle prestazioni e profili per la strumentazione
6. Applicare la sicurezza appropriata, ad esempio l'autenticazione di Windows (se ciò è richiesto dal client).
7. Gestione delle transazioni su ogni singolo metodo
8. Backup dei file dell'applicazione Web prima della nuova distribuzione della soluzione

Cos'altro?

La mia domanda è più legata al lato tecnico invece che funzionale / documentazione perché altrimenti andremo in un altro percorso :-)

Grazie.

Penso che la differenza più importante sia che l'obiettivo di un prototipo è:
1. Dimostrare che un problema può essere risolto in un certo modo OPPURE
2. Dare al cliente / management un'idea di come sarebbe il prodotto

mentre l'obiettivo di un sistema live è:
1. Per risolvere un determinato problema / affrontare un problema.

Si noti che gli obiettivi dei due sono completamente diversi .
Pertanto, a mio avviso, un prototipo dovrebbe essere gettato via prima di sviluppare un sistema live .

Questo anche perché un prototipo è di solito un progetto "rapido e sporco", messo insieme senza alcuna delle considerazioni che hai giustamente sottolineato nella tua domanda (come test, prestazioni, sicurezza e molto altro).
Quindi sarebbe meglio iniziare un nuovo progetto adeguato, piuttosto che cercare di migliorare un cattivo progetto.

Non tutte queste cose sono richieste, a seconda delle tue esigenze, o potrebbero esserci molte altre richieste. Se sai cosa intendo;) I test delle unità e la copertura del codice sono buone cose, ma a seconda di come procedi in altre parti del processo, potrebbe non essere necessario. Alcuni direbbero che più importante della profilazione delle prestazioni è un codice ben documentato o un manuale di formazione. Varia!

Mi rendo conto che stai guardando il lato tecnico, ma spero che capirai il mio punto, varia a seconda del lato non tecnico. O almeno, dovrebbe.

L'uso di contatori delle prestazioni e profilatori per la strumentazione .. potrebbe essere adatto, ma potrebbe essere eccessivamente massiccio. Potrebbe non essere richiesto.

Ciò che ti manca qui non riesce a tenere conto del contesto, dell'ambito e dei requisiti aziendali del progetto.

Per contesto e ambito intendo: stai creando qualcosa che può essere utilizzato internamente da un'azienda? Rivolti ai clienti? Utilizzato dagli utenti finali? È in effetti una versione jazz di Notepad o un nuovo RDBMS da zero? Ciò che dovrebbe essere incluso varierà enormemente (in modo massiccio!) Dal progetto che stai guardando.

Per requisiti aziendali non intendo i casi d'uso del software, ma i requisiti del processo di gestione / produzione del progetto. Se insisti di aver bisogno di tutte queste cose per un progetto di produzione, il costo si rifletterà di conseguenza (molto alto). Ciò potrebbe significare che è oltre il budget, in ritardo, o nemmeno dato il via libera per iniziare lo sviluppo.

Potrebbe essere più importante che avere una serie fissa di criteri ora sia semplicemente avere un buon quadro di produzione / sviluppo, alta visibilità e rilasci regolari in modo che la qualità possa essere valutata in questo modo. È possibile che nessuno sia coinvolto in una merda sulla copertura del codice.

È interessante notare che penso che i punti 1, 2, 4 e 7 dovrebbero essere già stati fatti durante il concepimento del prototipo, tranne per il fatto che non credo che dovresti testare tutti i metodi in ogni classe. Testare il codice critico, non se i metodi get / set si comportano correttamente.

A seconda dello scopo dell'applicazione, in cui la sicurezza è un grosso problema, il punto 6 può essere abbastanza critico da renderlo necessario nel prototipo. A seconda dello scopo dell'applicazione, in cui le prestazioni sono la chiave, il punto 5 può essere fondamentale ... Sai cosa intendo. La mia opinione è che i punti 3, 5 e 6 potrebbero essere necessari nel prototipo se considerati critici (il punto 8 è veramente valido per le applicazioni di produzione)

Modifica: sembra che la mia opinione differisca completamente da quella di Jonny perché intendo che considero il prototipo come base / shell / scheletro dei tuoi sviluppi futuri, quindi per me il prototipo non deve essere gettato via.

Oltre a quanto già menzionato, in un progetto di produzione è necessario quanto segue (tra gli altri):

0-Scegli una metodologia di implementazione

1-Finalizzare e pubblicare i requisiti principali (inclusi casi d'uso, ecc.)

2-Ottieni l'architettura giusta

3-Selezionare gli strumenti corretti

Database 4-Design per prestazioni

5-Produci il tuo design di classe e design del flusso di lavoro

6-Determinare e implementare una strategia per integrare database / fonti di dati / feed supportati

7-Definire e implementare i requisiti di sicurezza

8-Predisporre per l'implementazione fisica (server, connettività, licenze ecc.)

9-Pianificare i requisiti di archiviazione e determinare le misure delle prestazioni

10-Produci tutti gli artefatti e installali nell'ambiente di produzione

11-Test

12-Fornire la soluzione finale e implementare il feedback

La caratteristica più importante delle soluzioni di qualità della produzione è - a mio avviso - robustezza .

Indipendentemente da ciò che accade, la soluzione gestisce la situazione in modo ragionevole, avvisa coloro che hanno bisogno di sapere e continua (se l'errore è recuperabile).

Esistono due tipi di prototipi:

• Applicazioni "proof of concept" rapide e sporche che vengono "ripulite" e diventano codice di produzione. La fase di "pulizia" tende ad essere un incubo, oppure è in realtà una fase "spazzare i problemi sotto il tappeto", con il risultato di ingenti debiti tecnici.

• Prototipi "prototipo" o "wireframe". Questi possono essere schizzi dell'interfaccia utente di carta e matita, o anche modelli interattivi realizzati in una lingua in cui è possibile raggruppare rapidamente questo tipo di cose senza pensare a come combaciare. Dovrebbe usare dati falsi, nessuna vera architettura, ecc. Il punto è che danno agli stakeholder un'idea di come sarà il sistema, in modo che tu possa affinare i tuoi requisiti, ma NON POSSONO essere usati come parte della tua soluzione finale .

Preferisco il secondo tipo. Vengono buttati fuori, perché non c'è davvero scelta.

Dico di costruirlo come un progetto senza demo, ma ora puoi includere ciò che hai imparato dalla demo nel tuo design. La codifica iniziale può essere negativa anche quando si avvia la produzione. Dovrai comunque fare il refactoring di gran parte di esso.

Il vero problema da affrontare è la tua mancanza di tempo. Quando i decisori vogliono che tu continui a lavorare sulla demo, hanno l'impressione che gran parte dell'applicazione sia pronta, quindi non ci vorrà tanto tempo. Ho sentito che altri usano questa logica sul perché preferiscono mostrare schizzi ai clienti piuttosto che modelli troppo realistici. Presta attenzione al codice demo perché potrebbe aver scoperto problemi che non hai mai pensato e che probabilmente non hai documentato in questo processo. Ora devi considerarli (eccessivamente semplificati, ma sì, il database potrebbe non essere accessibile, ad esempio.).

Tutti i prototipi e le demo non sono creati uguali. L'intero codice potrebbe essere privo di valore o alcune parti potrebbero essere state eseguite molto bene. Non importa se si tratta di una demo, devi conoscere la differenza. Non lanceresti semplicemente un'app legacay e ricominceresti, vero? Dimentica che ho chiesto.