Come posso smettere di progettare e iniziare a progettare questo progetto come suggerito dal mio capo? [chiuso]

Sono uno sviluppatore junior (circa 3 anni) e nel mio lavoro stiamo progettando un nuovo sistema. Il mio sviluppatore principale sarà l'architetto principale, tuttavia mi ha sfidato a provare a progettare il sistema da solo (in parallelo).

Nel corso di alcune iterazioni di idee di brainstorming e di proposta di ciò che ho visto come suggerimenti di architettura, il mio esempio mi ha dato il feedback che la maggior parte di quello che ho fatto è stato "progettare" e non "architettare".

Ha descritto la differenza come architettura indipendente dall'implementazione, mentre un design è la descrizione di un'implementazione. Ha detto che devo togliermi il cappello da designer e indossare il cappello da architetto. Mi ha dato un piccolo consiglio su come farlo, ma vorrei chiedere anche a te:

Come uscire dalla modalità di progettazione software e iniziare a pensare più come un architetto?

Ecco alcuni esempi di "disegni" che mi sono venuti in mente che non sono stati considerati rilevanti per l'architettura dal mio esempio:

1. Ho escogitato un algoritmo per caricare e scaricare risorse dal nostro sistema e il mio capo ha detto che gli algoritmi non sono categoricamente architettura.
2. Ho inventato una serie di eventi che il sistema dovrebbe raccogliere e in quale ordine dovrebbe generarli, ma anche questo non sembra tagliarlo come architettura.

Mi sembra di essere coinvolto nei dettagli e di non fare abbastanza passi indietro. Trovo che anche quando trovo qualcosa che sia a livello di architettura, spesso ci sono arrivato provando varie implementazioni e rimuginando nei dettagli, quindi generalizzando e astrattizzando. Quando ho descritto questo al mio esempio, ha detto che stavo prendendo un approccio sbagliato: avevo bisogno di pensare "dall'alto in basso" e non "dal basso".

Ecco alcuni dettagli più specifici sul progetto :

• Il progetto che stiamo progettando è un'applicazione web.
• Sto stimando circa 10-100 mila righe di codice.
• Siamo una start up. Il nostro team di ingegneri è di circa 3-5 persone.
• La cosa più vicina a cui potrei confrontare la nostra applicazione è un CMS leggero. Ha una complessità simile e si occupa in gran parte di carico e scarico dei componenti, gestione del layout e moduli in stile plug-in.
• L'applicazione è ajax-y. L'utente scarica il client una volta, quindi richiede i dati di cui ha bisogno dal server.
• Useremo il modello MVC.
• L'applicazione avrà l'autenticazione.
• Non siamo molto preoccupati per il vecchio supporto del browser (wow!), Quindi stiamo cercando di sfruttare l'ultimo e il più grande che è là fuori e uscirà. (HTML5, CSS3, WebGL ?, Estensioni di sorgenti multimediali e altro!)

Ecco alcuni obiettivi del progetto :

• L'applicazione deve essere ridimensionata. Nel breve termine i nostri utenti saranno nell'ordine da centinaia a migliaia, ma stiamo pianificando da decine di migliaia a milioni e oltre.
• Speriamo che l'applicazione sia presente per sempre. Questa non è una soluzione temporanea. (In realtà abbiamo già una soluzione temporanea e quello che stiamo progettando è la sostituzione a lungo termine di ciò che abbiamo).
• L'applicazione deve essere sicura in quanto potrebbe avere contatti con informazioni personali sensibili.
• L'applicazione deve essere stabile. (Idealmente, sarebbe stabile attorno al livello di Gmail ma non deve essere all'estremo di un rover su Marte.)

Innanzitutto direi che la differenza tra architettura e design è principalmente la semantica. Alcune squadre hanno punti di controllo tra i due. Il tuo capo tecnico definisce l'architettura come prima il design e l'architettura come agnostici di implementazione. Da ciò presumo che stiamo parlando di design come nel modello a cascata e non di Industrial Design che ti aiuterebbe a progettare il prodotto in vista degli utenti prima di arrivare all'architettura del software. Penso che l'architettura spesso scivoli nel design e che non sia necessariamente una cosa negativa, spesso è molto utile per l'architetto avere una profonda conoscenza di ciò che è possibile all'interno del sistema a portata di mano.

Detto questo, hai bisogno di qualche consiglio per la situazione in cui ti trovi. Esiste un intero mondo di architettura software, documenti, libri, conferenze, ma in genere cerchi schemi e astrazioni. Senza ulteriori dettagli sul progetto, posso solo fare un ampio esempio. Ad esempio, se stavi lavorando in integrazione, c'è la Service Oriented Architecture ( SOA)) modello in cui dividi parti del sistema in "servizi" in modo da poter lavorare con ciascuna parte in un modo definito, nel programma Web questo viene spesso implementato come Servizi Web (anche se non dovrebbe essere considerato come limitato a quello) e più recentemente l'ascesa di API RESTful con JSON, direi ancora che questo è un design proveniente dall'architettura di SOA. Direi Model, View, Controller (MVC) è un altro esempio di un modello di architettura di uso comune, che suddivide la responsabilità dei componenti di un sistema per consentire lo scambio di parti, il contenimento di errori e il collaudo.

Da un livello di 10.000 piedi, se riesci a disegnarlo su una lavagna e spiegarlo a un programmatore competente che non lavora nel tuo campo e non conosce il tuo linguaggio di programmazione e i dettagli di implementazione attuali, probabilmente è l'architettura. Se riesci a scriverne un libro di cui a chiunque al di fuori della tua azienda piacerebbe, probabilmente è l'architettura. Se trovi i dettagli che ti spiegano da soli e non riesci a generalizzarli ad altre basi di codice / aziende / industrie, probabilmente è design.

Concordo sul fatto che i due esempi forniti sono la progettazione del codice e non l'architettura. Il primo perché penso che quando dici che ti è venuto in mente un "algoritmo" per caricare le risorse, penso che tu intenda che hai progettato una serie di istruzioni per svolgere quel compito, e non che hai progettato un nuovo algoritmo che insegneranno nel primo anno COMSC l'anno prossimo. Nel secondo esempio, sono di nuovo d'accordo sul fatto che sia design. Se mi mostrassi una di queste idee, non sarei in grado di usarle nel mio progetto software casuale. Devi passare a un "livello superiore", orientato agli oggetti (OO) in Java piuttosto che desidero che la classe cliente sia una sottoclasse della classe persona. Anche parlare di eccezioni in generale potrebbe essere considerato di livello troppo basso (troppo vicino all'implementazione).

Per cercare di affrontare le specifiche che elenchi, penso che dovresti pensare a come progettare un CMS basato sul web. Wordpress ha un codice di architettura del sito in cui parlano molto dei dettagli di implementazione del design, ma dal post emerge chiaramente che la loro architettura principale è incentrata sul rendere Wordpress estensibile con i temi. Progettare un'interfaccia chiara per un tema in modo che potesse essere scritto da qualcuno al di fuori dell'azienda era chiaramente una decisione di architettura che prendevano. Questi sono i tipi di cose che è utile mettere sulla carta quando si progetta la propria soluzione "a lungo termine" (non temporanea) in modo che tutte le decisioni di progettazione e implementazione che vengono prese durante lo sviluppo (da tutti gli sviluppatori, non solo dall'architetto) sono in linea con questa idea.

Altri esempi di architettura per la tua situazione:

1. Mettere il tutto su macchine virtuali, ospitate su un provider cloud o internamente e avere istanze di macchina senza stato, in modo che qualsiasi guasto alla macchina possa essere sostituito con una nuova istanza di una macchina virtuale senza dover copiare in alcuno stato o perdere alcuna informazione.
2. Costruire nei test di fallimento della produzione dal vivo sin dall'inizio con i caos simian .

Forse prova a disegnare l'intero sistema su una lavagna. Provalo a diversi livelli di dettaglio, la prima scheda potrebbe essere GUI-> dispatcher-> backend-> DB o qualcosa del genere, e quindi approfondire fino a quando non inizi a usare i pronomi.

La distinzione tra queste due idee è davvero importante dove lavoro.

Quello che tu chiami "architettura", noi chiamiamo "programmazione in inglese". Questo è in parte importante perché se non puoi descriverlo a un non programmatore, allora qualcosa non va. È possibile che tu non capisca abbastanza bene il problema, O potrebbe essere che stai risolvendo un problema "fantasma" (non discusso qui).

I termini utilizzati per questi due diversi aspetti del design sono spesso diversi, ma i principi sono facilmente riconoscibili ovunque. Un aspetto (nel tuo caso l'architetto, nel mio caso il designer) programma in inglese, mentre l'altro (nel tuo caso "designer", nel mio caso "sviluppatore") programma in una lingua particolare. Sono anche abbastanza comunemente distinti come "design" e "implementazione". "Design" è ciò che dovrebbe realizzare, e "implementazione" è il codice che lo rende possibile.

Alcuni esempi di ciò su cui ho lavorato:

L'architettura di un programma è: abbiamo bisogno di un Manager o hub centralizzato a cui possiamo facilmente aggiungere moduli. Questo Manager distribuirà gli eventi a tutti i moduli registrati. Un modulo può registrarsi con Event Manager e quindi pubblicare eventi nel resto del sistema e ricevere eventi a cui tiene. Ogni modulo ha una "cassetta postale" che può controllare e svuotare come preferisce. Questo ci permetterebbe di accogliere nuovi moduli di cui non sappiamo di aver ancora bisogno.

Nessun codice lì. Potrebbe essere scritto in qualsiasi lingua. L'implementazione non è dettata da questa descrizione.

L'architettura di un altro progetto è: abbiamo bisogno di un modo per avviare e arrestare in modo affidabile altri programmi senza aspettarli. Potremmo avere un manager che è responsabile di un determinato programma. Possiamo solo dirgli di avviare o interrompere il suo programma e il gestore se ne occupa. Se a questo altro programma viene chiesto di fermarsi e non lo fa in un determinato periodo di tempo, il gestore sa come forzarlo a fermarsi e ripulire il casino. Il programma non viene avviato o arrestato da nient'altro e al gestore può essere chiesto se il programma è in esecuzione, arrestato o in attesa di interruzione. Questo ci consente di continuare con le altre cose che dobbiamo fare, pur facendo avviare e arrestare correttamente questi altri programmi.

Ancora una volta, nulla qui impone l'implementazione, sebbene alcune implementazioni siano chiaramente più utili di altre.

La differenza tra design (quelli che chiameremmo pattern o implementazione) e architettura (che chiameremmo design) è che uno di loro risolve un problema di codifica / implementazione e l'altro risolve un problema del mondo reale.

Forse questo aiuterà. Ho sempre visto l'anzianità di un ingegnere come una questione di quanto sia grande un problema che possono risolvere da soli.

In parole povere, per trasmettere l'idea:

• Puoi dare a qualcuno che è nuovo programmatore compiti piccoli e contenuti con molte istruzioni esplicite su come il compito deve integrarsi con altri pezzi

• Uno sviluppatore di medio livello è qualcuno che può prendere una descrizione di una parte di un'applicazione e farla funzionare nel contesto di quell'applicazione.

• Uno sviluppatore senior può creare da zero un'applicazione di medie dimensioni, entro i limiti tecnici di un negozio.

• Un dev più anziano può farlo, e fare scelte tecnologiche lungo la strada su quali tecnologie usare per farlo funzionare bene.

... ma quelle non sono regole rigide e veloci. E alcune persone escono dal cancello come IMHO "senior", anche se devono passare un po 'di tempo con un titolo diverso.

Ciò che l'architetto sta chiedendo è di vedere il problema ancora più in generale. Se hai dovuto mettere insieme un numero di applicazioni per far funzionare il sistema:

• Di quali applicazioni e servizi avrai bisogno?
• Quali pezzi interagiscono con i clienti e quali interagiscono tra loro?
• Come comunicheranno?
• Dove memorizzeranno i dati?
• Dove sono i rischi di guasti?
• Come fornirai affidabilità?
• Come fornirai sicurezza?

Quindi, in un certo senso, l'architettura tecnica è come un'architettura da costruzione. È il layout o il piano. Mostra ciò che è necessario per le varie parti, come si tengono insieme e altrettanto importante perché .

(A proposito, ho avuto una curva di crescita simile spiegata per gli architetti, che vanno dall'architettura di una famiglia di applicazioni correlate o da una serie di funzioni molto complesse, alla definizione di una direzione tecnica per un gruppo, a prendere decisioni tecniche strategiche per un'intera organizzazione .)

Detto questo, penso che la maggior parte degli ingegneri di tutti i livelli debbano fare anche un po 'di "architettura". Non è una linea brillante. Sembra che se ti concentri prima sul Big Picture e non ti blocchi sui dettagli di implementazione, sarai più in linea con quello che sta cercando. A proposito, la capacità di vedere il quadro generale e i piccoli dettagli è una risorsa enorme in questo settore, quindi sembra una grande opportunità.

... Ecco un'analogia. Supponiamo che ti venga chiesto di creare una scatola nera magica. Come ingegnere, dovresti essere ossessionato dal funzionamento interno della Magic Black Box. Ma come architetto, il tuo focus è diverso. Potresti sbirciare nella scatola per curiosità, ma ti aspetti che sia ossessionato da tutto ciò che riguarda tutte le Magic Black Box.

Simile a tale analogia, potresti pensare al ruolo dell'architettura come visualizzare l' intero sistema come la scatola magica. Quindi, se prendi una Gigantic Glass Box e metti dentro i clienti, le app client, il firewall, il livello di servizio, il database e persino i ragazzi devops, allora come architetto sei ossessionato su come realizzare quell'enorme box di sistema funziona bene .

La differenza esatta tra "design" e "architettura" è un po 'soggettiva e c'è qualche sovrapposizione. Tuttavia, questa è la differenza per come la capisco:

L'architettura guarda a concetti di alto livello. Chi sono gli attori nel sistema? Quali sono gli oggetti principali e quali sono i responsabili di cosa? Quando penso all'architettura, penso a Visio, non al codice.

Ad esempio, un sistema di eventi potrebbe avere un gestore eventi che accetta gli eventi in arrivo e li invia ai gestori di eventi. L'idea di thread, asincrono v. Sincrono e altri concetti di livello inferiore non entrano in gioco qui. MVC è un altro esempio: i dettagli specifici non sono specificati al livello elevato di come i tre pezzi interagiscono, solo che ci sono tre preoccupazioni separate gestite da pacchetti di codice separati.

Il design prevede la prototipazione, il disegno di interfacce di codice, scheletri di codice, ecc. Si colloca tra l'architettura astratta e il lavoro di "scimmia codice" di basso livello.

In un framework di eventi, il progetto potrebbe dire "un evento utilizza questa interfaccia" e "esiste un pool di thread che il gestore eventi utilizza per inviare eventi ai lavoratori". Un progetto per MVC potrebbe essere "usa Hibernate per il modello, Spring per il controller e GWT per la vista".

Quando lavoro in progettazione, ho delineato interfacce e scheletri di codice, quindi trasmetto i risultati ai programmatori. A volte sono quel programmatore. Ma sono due fasi separate ed entrambe esistono più verso il concreto che verso l'architettura.

Indossare il cappello dell'architettura significa liberare la mente dal codice e pensare agli oggetti su una lavagna. Pensa agli oggetti, ai pacchetti, ai framework e al flusso di messaggi tra di loro. Se stai pensando anche a una sola riga di codice, stai sbagliando. Non impantanarti in qualcosa del tipo "oh, quel messaggio potrebbe essere una stringa, o usare SOAP, o altro". A questo livello, il fatto che si stia verificando la comunicazione è sufficiente. I dettagli sono irrilevanti.

Se posso aggiungere qualcosa qui, è questo: non pensare al codice . Affatto.

Non pensare a come scrivere il codice per realizzare qualcosa, ma pensa a quale sarebbe il metodo migliore per realizzarlo. La tua descrizione di ciò che devi fare dovrebbe essere indipendente dal linguaggio , quindi parlerai di modelli di progettazione - che sono un "linguaggio" comune tra utenti di diversi linguaggi di programmazione - per discutere su come procedere.

Per il tuo caso d'uso specifico, più domande architettoniche secondo me sarebbero sulla falsariga di:

• Perché stai usando MVC? È tutto ciò che sai? Ci sono schemi migliori da usare? Perché?
• Quale framework utilizzerai e perché ?
• Come scalerai? Non per quanto riguarda il codice, perché non ha ancora importanza. Quali saranno le condizioni per ridimensionare orizzontalmente; quale servizio (AWS) userete per fare questo?
• Come verrà eseguita l'autenticazione? Non dal punto di vista del codice: stai per generare un token casuale e univoco su ogni richiesta e averlo verificato rispetto al token previsto? Non pensare a come lo farai nel codice. Pensa al motivo per cui lo stai facendo, perché questo può essere fatto praticamente in qualsiasi linguaggio web.

Fondamentalmente, non parlare affatto di codice. Anche se non sai come fare qualcosa, quando c'è una volontà, c'è un modo . Pensa di più su come i pezzi del puzzle si adatteranno meglio prima di preoccuparti di metterli insieme.

Pensa a tutte le operazioni (es. Casi d'uso) che il tuo sistema può eseguire. Per ogni operazione, documenta cosa succede in termini di dominio aziendale per ciascuna operazione. Dovresti parlare solo in termini di dominio problematico e non descrivere alcun dettaglio di implementazione. Disegna un grosso blocco e chiamalo Sistema. La combinazione di questo "grande blocco" e le descrizioni delle operazioni è l'architettura di sistema di massimo livello.

Sebbene questa architettura di alto livello fornisca un discreto punto di partenza, in realtà non ha molto valore quando si costruisce un sistema reale. Devi ridurlo a un livello di dettaglio per trasformarlo in un'architettura utile.

Quindi segui la stessa idea generale dell'approccio "big block" solo quando inizi ad aggiungere "sottoblocchi" necessari per eseguire ciascuna operazione. Questi "blocchi secondari" sono spesso chiamati classi o moduli di dominio. Questi sono facilmente identificabili usando le descrizioni delle operazioni (dall'approccio big block) e disegnando diagrammi di sequenza. Sono chiamate classi di dominio perché non sono pensate per essere classi "reali", ma hanno lo scopo di descrivere il tuo sistema in termini di dominio problematico del tuo sistema.

Il risultato finale della creazione di tutto il diagramma di sequenza e dell'identificazione di tutti i "blocchi secondari" è che ora si dispone di un elenco di classi di dominio e dei relativi elenchi di operazioni. Questo di solito si traduce in un'architettura software abbastanza utilizzabile, in cui ciascuno dei "blocchi secondari" / moduli può essere distribuito a diversi sviluppatori per progettare e implementare.

Naturalmente, se lo lasci così com'è, i tuoi progettisti avranno molta interazione tra loro nella definizione delle interfacce tra i moduli. Pertanto, l'architetto può anche decidere i meccanismi di interfaccia specifici e i tipi di dati da utilizzare tra i moduli.

Inoltre, alcuni "sottoblocchi" saranno ancora molto complicati. Quindi potrebbe essere necessaria un'altra iterazione dell'approccio "sottoblocco", ma solo questa volta su uno dei moduli appena identificati.

Infine, potrebbero esserci alcuni schemi / limitazioni specifici tra le interfacce a cui l'architetto vuole che il sistema aderisca (ad es. Callback di eventi rispetto a chiamate di metodo dirette), quindi tali decisioni dovrebbero essere discusse nella progettazione architettonica. Inoltre, potrebbero esserci moduli "comuni" che l'architetto vuole che tutti usino.

Come sviluppatore, probabilmente sei abituato a fornire soluzioni. Questo è un ottimo modo di pensare, ma può ostacolarti quando si tratta di pensare all'architettura.

Trovo che aiuti a descrivere il problema che stai cercando di risolvere per primo. Quali sono i requisiti? Quali sono i vincoli? Puoi parlare con le parti interessate per scoprire questi requisiti?

Potrebbe essere utile descrivere anche i tuoi obiettivi di progettazione. La tua soluzione deve essere ridimensionata o è sufficiente una progettazione per singolo utente? Per quanto tempo deve rimanere valida la tua soluzione? È una soluzione una tantum o una soluzione di infrastruttura a lungo termine? Forse anche importante: quali sono i limiti accettati della tua architettura?

E poiché questa è un'esperienza di apprendimento, non aver paura di fare domande, anche se sono sciocche.