Come posso smettere di progettare e iniziare ad architettare questo progetto come suggerito dal mio lead? [chiuso]

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 del design e dell'architettura come indipendente dall'implementazione. Da ciò presumo che stiamo parlando di design come nel modello a cascata e non in quello di disegno industriale che potrebbe aiutarti a progettare il prodotto in un'ottica di visibilità per gli 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 un consiglio per la situazione in cui ti trovi. C'è un intero mondo di architettura software là fuori, documenti, libri, conferenze, ma in genere cerchi schemi e astrazioni. Senza ulteriori dettagli sul progetto, posso solo dare un ampio esempio. Ad esempio, se lavoravi nell'integrazione c'è l'Architettura orientata ai servizi ( 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 limitato a tale ) e più recentemente l'aumento delle API RESTful con JSON, ancora una volta direi che questo è un progetto proveniente dall'architettura di SOA. Direi che 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 delle parti, contenere errori e test.

Da un livello di 10.000 piedi, se puoi 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 correnti, probabilmente è architettura. Se puoi scrivere un libro su di esso che a qualcuno al di fuori della tua azienda interesserebbe allora è probabilmente architettura. Se ti accorgi a spiegare i dettagli e non puoi generalizzarli ad altre basi di codice / aziende / industrie, probabilmente è design.

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

Per cercare di rispondere alle specifiche che elencherai, penso che ciò a cui dovresti pensare è come progettare un CMS basato sul web. Wordpress ha un codice di architettura del sito dove parla molto dei dettagli di implementazione del progetto ma è chiaro dal post che la loro architettura principale ruota intorno a rendere Wordpress estensibile con temi. Architettare un'interfaccia chiara per un tema tale da poter essere scritta da qualcuno fuori dalla società era chiaramente una decisione di architettura presa. Questi sono i tipi di cose che è bene mettere giù sulla carta quando architetti la tua soluzione 'a lungo termine' (non temporanea) in modo che tutte le decisioni di progettazione e implementazione che vengono fatte durante lo sviluppo (da parte di tutti gli sviluppatori non solo l'architetto) sono in linea con questa idea.

Altri esempi di architettura per la tua situazione:

1. Mettere il tutto su macchine virtuali, ospitato su un provider di cloud o in house e con istanze di macchine senza stato, in modo che qualsiasi guasto della macchina possa essere sostituito con una nuova istanza di una macchina virtuale senza dover copiare in uno stato o perdere qualche informazione.
2. Costruire test di fallimento della produzione dal vivo con mostri del caos .

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, quindi eseguire il drill-down fino a quando non inizierai a utilizzare i pronomi.

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

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

I termini usati per questi due diversi aspetti del design sono spesso diversi, ma i principi sono facilmente riconosciuti 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 particolare lingua. Sono anche comunemente distinti come "design" e "implementazione". "Progettare" è 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 è la seguente: abbiamo bisogno di un Manager o hub centralizzato a cui possiamo facilmente aggiungere moduli. Questo Manager distribuirà eventi a tutti i moduli registrati. Un modulo può registrarsi con Event Manager, quindi pubblicare eventi nel resto del sistema e ricevere eventi a cui tiene conto. Ogni modulo ha una "casella di posta" che può controllare e svuotare a suo piacimento. Questo ci permetterebbe di accogliere nuovi moduli che 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 doverli attendere. Potremmo avere un manager che è responsabile di un particolare programma. Possiamo solo dirlo per avviare o interrompere il suo programma e il manager si prende cura di esso. Se si chiede a questo altro programma di fermarsi e non in un dato periodo di tempo, il manager sa come forzarlo a fermarsi e ripulire il pasticcio. Il programma non viene avviato o fermato da qualcos'altro e al manager può essere chiesto se il suo programma è in esecuzione, arrestato o in attesa di arresto. Questo ci permette di continuare con le altre cose che dobbiamo fare, mentre continuiamo a ricevere questi altri programmi avviati e fermati correttamente.

Anche in questo caso, nulla impone l'implementazione, sebbene alcune implementazioni siano chiaramente più utili di altre.

La differenza tra design (quello che chiameremmo pattern o implementazione) e architettura (quello 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 grosso problema possano risolvere da soli.

Approssimativamente, per trasmettere l'idea:

• Puoi dare a qualcuno di nuovo la possibilità di programmare piccole attività contenute con molte istruzioni esplicite su come l'attività deve essere integrata con altri pezzi

• Un dev di livello medio è qualcuno che può fare una descrizione di una parte di un'applicazione e farlo funzionare nel contesto di tale applicazione.

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

• Uno sviluppatore più anziano può farlo e fare scelte tecnologiche lungo il percorso riguardo a quali tecnologie utilizzare per farlo funzionare bene.

... ma quelle non sono regole dure 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 in modo ancora più generale. Se dovessi mettere insieme un numero di applicazioni per far funzionare il sistema:

• Quali applicazioni e servizi ti serviranno?
• Quali pezzi interagiscono con i clienti e interagiscono tra loro?
• Come comunicheranno?
• Dove memorizzeranno i dati?
• Dove sono i rischi di guasti?
• In che modo fornisci affidabilità?
• In che modo fornisci sicurezza?

Quindi, in un certo senso l'architettura tecnica è come un'architettura dell'edificio. È 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 a me spiegata per gli architetti, spaziando dall'architettura di una famiglia di applicazioni correlate o di una serie di caratteristiche molto complesse, all'impostazione della direzione tecnica per un gruppo, alle decisioni tecniche strategiche per un'intera organizzazione.)

Detto questo, penso che la maggior parte degli ingegneri di tutti i livelli debba anche fare un po 'di "architettura". Non è una linea luminosa. Sembra che se ti concentri per prima cosa sul Big Picture e non rimani impigliato nei dettagli di implementazione, sarai più in linea con quello che sta cercando. A proposito, la possibilità di vedere il Big Picture così come i Little Details è una grande risorsa in questo settore, quindi questa sembra una grande opportunità.

... Ecco un'analogia. Diciamo che ti viene chiesto di creare una scatola nera magica. Come ingegnere, ti devi ossessionare per il funzionamento interno della Magic Black Box. Ma come architetto, la tua attenzione è diversa. Potresti sbirciare dalla scatola per curiosità, ma ti devi ossessionare da ogni cosa intorno a tutte le Magic Black Boxes.

Simile a questa analogia, potresti pensare al ruolo dell'architettura come visualizzazione del intero sistema come scatola magica. Quindi, se prendi una Gigantic Glass Box e metti i clienti, le app del cliente, il firewall, il livello di servizio, il database e persino i ragazzi devopi all'interno, allora come architetto devi ossessionarti su come realizzare questa enorme scatola di sistemi lavora bene .

L'esatta differenza tra "design" e "architettura" è un po 'soggettiva e c'è qualche sovrapposizione. Tuttavia, questa è la differenza perché ho capito:

Architecture esamina i concetti di alto livello. Chi sono gli attori nel sistema? Quali sono gli oggetti principali e quali sono 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 eventi in arrivo e li invia ai gestori di eventi. L'idea di thread, asincroni v. Sincroni 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 interagiscono i tre pezzi, solo che ci sono tre problemi separati gestiti da pacchetti di codice separati.

Design prevede la prototipazione, lo sketch di interfacce di codice, scheletri di codice, ecc. Si trova tra l'architettura astratta e il lavoro di "code monkey" di basso livello.

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

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

Mettendo il cappello dell'architettura significa liberare la mente dal codice e pensare gli oggetti su una lavagna. Pensa a oggetti, pacchetti, strutture e il 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 qualsiasi altra cosa." A questo livello, il fatto che la comunicazione stia avvenendo è sufficiente. I dettagli sono irrilevanti.

If I can add anything here, it's that: don't think code. At all.

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

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

• Perché stai utilizzando MVC? È tutto ciò che conosci? Ci sono modelli migliori da usare? Perché?
• Quale framework utilizzerai e perché ?
• In che modo ridimensionerai? Non in base al codice, perché non ha ancora importanza. Quali saranno le condizioni per scalare orizzontalmente; quale servizio (AWS) userai per fare questo?
• In che modo è l'autenticazione che verrà eseguita? Non in base al codice: stai per generare un token univoco e casuale su ogni richiesta e averlo confrontato con il token previsto? Non pensare a come lo farai in codice. Pensa a perché stai facendo questo - 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ù a 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 ogni operazione. Si dovrebbe parlare solo in termini di dominio del problema e non descrivere i dettagli di implementazione. Disegna un blocco grande e chiamalo Sistema. La combinazione di questo "blocco grande" e delle descrizioni delle operazioni è l'architettura di sistema di più alto livello.

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

Quindi segui la stessa idea generale dell'approccio "big block" solo tu inizi ad aggiungere "sub-blocchi" che sono necessari per compiere ogni operazione. Questi "sotto-blocchi" sono spesso chiamati classi di dominio o moduli. Questi sono facilmente identificabili usando le descrizioni delle operazioni (dall'approccio a blocchi grandi) e disegnando i diagrammi di sequenza. Si chiamano classi di dominio perché non sono intese come 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 l'identificazione di tutti i "sotto-blocchi" è che ora hai un elenco di classi di dominio e i loro elenchi di operazioni. Questo di solito finisce con il risultato di un'architettura software abbastanza utilizzabile, in cui ciascuno dei "sotto-blocchi" / moduli può essere parcellizzato a diversi sviluppatori per progettare e implementare.

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

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

Infine, potrebbero esserci alcuni schemi / limitazioni specifici tra le interfacce che l'architetto desidera che il sistema rispetti (ad esempio callback degli eventi rispetto alle chiamate dirette ai metodi), quindi è necessario parlare di tali decisioni nella progettazione architettonica. Inoltre ci possono essere moduli "comuni" che l'architetto vuole che tutti usino.

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

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

Potrebbe aiutarti se riesci a descrivere anche i tuoi obiettivi di design. La tua soluzione deve essere in scala o è sufficiente un progetto per singolo utente? Quanto dura la tua soluzione per rimanere valida? È una soluzione unica o una soluzione infrastrutturale a lungo termine? Forse è altrettanto importante: quali sono i limiti accettati della tua architettura?

E dal momento che questa è un'esperienza di apprendimento, non aver paura di fare domande, anche se sono stupide.