Come pensi e programmi architetto? [chiuso]

Alcuni sviluppatori progettano i loro progetti in UML completamente prima di iniziare qualsiasi codice, e altri semplicemente saltano dentro. Ho visto buoni progetti in entrambi i modi. Credo che la chiave sia aperta alla riprogettazione e al refactoring in qualsiasi fase dello sviluppo. Un design splendidamente architettato, concepito in un documento di 300 pagine e compilato con una pila di diagrammi di stato e di sequenza, può essere spazzatura quando viene codificato.

Sii disposto a gettare il tuo lavoro ogni volta che è necessario. Avere i test in atto per dimostrare che il design refactored funziona correttamente dopo le modifiche come prima. Avere test di cui ti fidi ti darà il coraggio di cambiare.

La migliore definizione che ho trovato finora per l'architettura è qualcosa di simile: quando impari a leggere il tempo fuori da un orologio, in pratica hai imparato a conoscere la sua architettura. Che ci saranno almeno due aghi: uno grosso e corto che denota l'ora e un altro più sottile e più lungo che denota i minuti, che si muove in una certa direzione.

Il design d'altra parte riguarda il modo in cui l'orologio appare e si sente. Ha inciso tutte le dodici ore? Funziona con il quarzo o devi caricarlo ogni giorno? È alto 10 'o è un orologio da polso?

L'implementazione consiste nel fare in modo che le parti che fanno il segno di spunta (puntura non voluta) che è il design si attenga alle regole fondamentali stabilite dalla nostra architettura.

L' articolo di Wikipedia a parte ti suggerisco di passare attraverso Sito WebSEI per ulteriori informazioni sull'architettura software. Questo articolo su IBM è un buon inizio.

Sul lato più pratico ci sono cose chiamate schemi architettonici che riducono significativamente la quantità di lo sforzo necessario per investire sulla definizione di un'architettura quando inizi a scrivere un'applicazione nuova di zecca.

A volte un prototipo può essere un ottimo modo per scoprire alcuni possibili modi di sbagliare. Non attaccarti al prototipo, non preoccuparti dei dettagli a meno che non si tratti di un dettaglio che influirà sul sistema nel suo insieme, basta usarlo per capire il problema. Dopo aver esaminato correttamente il problema, puoi avviare un nuovo prototipo oppure, se ritieni che il tuo progetto di base sia corretto, puoi avviare un processo di progettazione più dettagliato.

Penso che dovresti iniziare a scrivere il codice non appena avrai una chiara visione di come verrà scritto, dopo 10 minuti di riflessione o dopo 10 giorni.
Per raggiungere questo obiettivo, è necessario utilizzare tutti gli strumenti a disposizione in base all'obiettivo: trovo i mock-up estremamente utili quando ho bisogno di capire le richieste, i diagrammi dei database per la progettazione della struttura DB e gli schemi delle classi per il codice (anche se quella parte a volte salta: -)).