Puoi prototipare un cambiamento di sistema complesso?

Mi sembra che sia possibile distinguere tra il codice che fa il lavoro e il codice che comunica tra i server. Mi piace la differenza tra Apache e TCP / IP. È possibile prototipare la nuova rete di comunicazione tra i server senza disporre di codice di lavoro di livello superiore. Se esiste una rete esistente che funziona correttamente, lasciala in pace e costruisci la tua rete di comunicazione prototipo indipendente da quella. Intercollegare psuedo-app piuttosto che le app reali. Questo può essere prototipato e testato.

Un altro passo potrebbe essere quello di "intercettare" il sistema esistente. Quando il sistema S1 ha detto "Ciao" al sistema S2, il tuo codice X1 vedrebbe S1 dire "Ciao" e trasmetterlo al tuo codice X2 che poi confronta quello che ha sentito da X1 e quello che S2 ha sentito da S1.

Non c'è molto da vedere sullo schermo, ma potresti proteggere la porzione critica del tuo nuovo sistema.

Il tuo application server è suddiviso in micro moduli o kernel (ala JBoss)? In tal caso potresti forse prototipare il core minimo distribuito tra le macchine.

Ovviamente dovrai chiarire che aspetti come remoting, messaggistica e txns distribuiti devono ancora essere elaborati, ma almeno avrai un inizio.

Se stai parlando di un server per app monolitico a sfera, allora sì è improbabile che tu possa prototiparlo rapidamente. In tal caso, suggerirei di creare un "pagliacciaio" che rappresenti i punti deboli di ciò che stai cercando di ottenere. Hmm, probabilmente non era chiaro. Ad esempio, potresti creare alcune classi che rappresentano una parte mobile del server delle app (ad esempio le transazioni) e implementare la tua idea di distribuzione su questo.

Con la prototipazione significano un vero prototipo di codice, o sono in realtà alla ricerca di un progetto dettagliato? Forse stanno cercando schermi o interfacce finte e li chiamano semplicemente protoptyes? Se stanno cercando un prototipo di codice prima o insieme al design, è una cattiva idea. Prepara per prima cosa il design di livello superiore e discuti con il tuo team / cliente. Il via per il design dettagliato e le interfacce. Convincerli che firmare un codice "prototipo" non è realmente possibile.

Di solito i prototipi o gli stub invlove una grande quantità di codice e non dovrebbero essere fatti a meno che tu non abbia davvero bisogno di un "proof-of-concept": mostrare che qualcosa può (o non può essere fatto) (qualcosa come cambiare in un nuovo libreria o porting di un'app). O forse hai bisogno di stub per implementare il codice di livello superiore senza creare prima il codice di livello inferiore. Non so se questo è il tuo caso, ma se non c'è un uso giustificato per il tuo prototipo, opponi l'idea educatamente ma con fermezza.

È molto raro che i problemi non possano essere suddivisi in blocchi più piccoli. Più il progetto è complesso, più pezzi possono essere suddivisi.

Se dovessi progettare un'applicazione distribuita da zero, sicuramente il risultato finale non sarà il primo risultato da testare. Proprio come quando progetti un videogioco, ad esempio, puoi assicurarti che i tuoi comandi video di base funzionino, quindi lavorare sull'interazione dell'utente, quindi lavorare sui bit dello scenario di gioco ... Lo stesso con un'applicazione distribuita.

Detto questo, un prototipo, o una dimostrazione di concetto, generalmente non è direttamente correlato all'applicazione su cui lavori. Si tratta di un'applicazione semplificata che dimostra i requisiti chiave o le funzionalità di progettazione che si intende implementare.

Se un prototipo o una dimostrazione di concetto è un investimento adatto o meno è per te discutere con il tuo capo, con le tue conoscenze e situazioni specifiche. Ma generalmente non penso che ci siano molte situazioni in cui ciò non è possibile. Potrebbe non essere redditizio o efficace nel tempo, oppure potresti non sapere come crearne uno efficacemente.

Tieni presente che un prototipo, a seconda di cosa si intende dimostrare, non deve necessariamente essere costruito utilizzando gli stessi strumenti del prodotto finito. Soprattutto se stai solo provando a dimostrare i concetti generali & architettura. Se riesci a ridurre i requisiti ai più piccoli concetti significativi che devono essere testati per convincere il tuo capo a investire di più, allora hai la definizione di ciò che dovrebbe essere il tuo prototipo.

Quindi il tuo punto di partenza prima di dire hey o nay è quello di ricontrollare con il tuo capo cosa li preoccupa esattamente con l'approccio del big bang (tutto in una volta sola). E vedi cosa puoi fare per dimostrare, nel modo più semplice possibile, perché è una buona idea portare avanti lo sviluppo. Se non riesci a farlo con un prototipo, potresti essere in grado di farlo con simulazioni o analisi (e creare un solido caso aziendale).

Tutto può essere prototipato

Se un problema sembra essere troppo complesso per essere prototipato, allora suddividilo in problemi più piccoli e prototipa ognuno di questi.

Tuttavia in questo caso significano che vogliono vedere se le modifiche sottostanti funzioneranno, prima di andare a cambiare l'applicazione esistente.

Tu - ovviamente - non puoi farlo nell'app esistente senza effettivamente fare tutto il lavoro, quindi quello che stanno cercando è una semplice applicazione di esempio leggera (codice nuovo di zecca) che esercita i meccanismi che inserirai nel app esistente.

Questo nuovo prototipo dovrebbe essere il più semplice possibile, continuando a esercitare le aree problematiche dell'applicazione esistente (il più semplice possibile, ma non più semplice).

Possono eseguire il benchmark del prototipo per il consumo di memoria / bilanciamento del carico, ecc. e dimostrare che lo sforzo di aggiornare l'app esistente è conveniente.

Sì , dovresti prototipare anche modifiche di software complesse e di grandi dimensioni.

Il vecchio adagio, "misura due volte, taglia una volta" si applica qui. Dalla tua prototipia, otterrai una comprensione inestimabile del comportamento del sistema e dei potenziali problemi che potresti incontrare nei cambiamenti reali. Ciò che apprendi potrebbe influire drasticamente sulla soluzione finale! È facile pensare di aver preso in considerazione tutte le implicazioni, ma soprattutto con modifiche grandi e complesse che non possiamo avere. Ci sono sicuramente problemi o dipendenze che abbiamo perso. Vuoi che la tua soluzione finale sia originale e pronta per la produzione.

Michael Feathers raccomanda una tattica simile nel suo libro, Lavorare efficacemente con il codice legacy - scratch refactoring (pp. 212-213,264): "Basta entrare lì", dice, "e iniziare a spostare le cose intorno e rendere il codice più chiaro ... basta non controllare in ..." Fai questo per ottenere una migliore comprensione del codice e per individuare i problemi che dovrai risolvere una volta che sei pronto per apportare i cambiamenti reali.