Quanto progetto si verifica nella fase di implementazione?

Sono un grande fan della prototipazione rapida, dell'incremento rapido e della rapida iterazione. evoluzione piuttosto che "design intelligente". stai scrivendo software per risolvere problemi per le persone e le persone tendono a cambiare idea e necessità nel tempo, anche per brevi periodi di tempo.

è bello avere requisiti, una vista a volo d'uccello, e "firmare" il più lontano possibile prima di programmare, ma non ha molto senso essere dogmatico, è tutto fluido. essere pronti a modificare, modificare e buttare via il codice mentre si va. la cosa divertente è che non arrivi mai ad un punto di completamento in ogni caso ... la maggior parte del codice sembra cambiare mentre la gente si preoccupa di esso, e poi, una volta che nessuno se ne importa, viene semplicemente cancellato.

ora per essere certi che questo non si applicherà ai bit del software che funzionano come prima cosa come i sistemi di controllo degli aerei, i controlli dei reattori nucleari, ecc., ma suppongo che non sia il tuo caso.

C'è sempre qualcosa mancato nella fase di progettazione. Le persone sono imperfette e, anche con una gestione perfetta che consente molte fasi di progettazione senza la necessità di passare all'implementazione, ci saranno cose che ti sono sfuggite.

Allo stesso modo, nel design, si inserisce un punto di rendimenti decrescenti. Ad esempio, se si progetta un'interfaccia utente e si scrive in una specifica, è possibile raggiungere rapidamente il punto in cui la specifica contiene il layout, la formattazione e tutta la logica di un modulo. In questo caso è praticamente identico all'implementazione, con forse solo i bit disordinati della colla del codice che sono diversi.

Hai bisogno di interrogare il valore di spingere il design troppo lontano: quando il design si trasforma in scrittura del codice perché questo è il modo più chiaro per trasmettere il tuo intento, è tempo di chiedere se è abbastanza sufficiente.

L'implementazione, quindi, comincerà a scoprire cose dimenticate o perse, così come altri dettagli di implementazione che potrebbero sembrare facili ma che risultano non essere. (Forse i servizi che pensavi di poter ottenere da una libreria o dal tuo sistema operativo, risultano non del tutto attendibili ... e devi fare un po 'di scavo o scrivere un sacco di nuovo codice come soluzione, shim o patch.)

Waterfall è un modello semplice e adorabile, ottimo per spiegare al management. È anche abbastanza lontano dal pensiero iterativo e misto di alto livello / basso livello che accade nella realtà.

Un commento un po 'più interessante su questo può essere trovato in un vecchio libro: "Declino e caduta del programmatore americano" di Ed Yourdon.

So che questa non è una risposta perfetta, ma poi, programmazione e amp; anche le metodologie di progettazione non sono perfette. L'approccio migliore per loro è trattarli come un sistema utile per fare le cose. Le regole sono lì per AIUTARTI e per essere infrante quando si mettono di mezzo. La rottura delle regole dovrebbe essere fatta in modo intelligente, non semplicemente perché qualcuno ha avuto voglia di tagliare il codice dal primo giorno.