Funzionalità

Il design può arrivare più tardi, la funzionalità di base è la chiave per un prodotto consegnabile.

Ignorando il design, la chiave è ottenere un prodotto funzionante disponibile fuori dalla porta prima piuttosto che dopo. Il design è un obiettivo secondario. Se non riesci a farlo funzionare, allora tutti i fiori e i bei colori non ti salveranno. Avere un prodotto funzionante, con un minimo di lavoro di progettazione sarà.

Aderire perfettamente a un pattern o ai principi OOP sono grandiosi, ma spesso troverai che, per produrre qualcosa che funziona , in alcuni casi dovranno essere ignorati.

Non è insolito (e in qualche modo è raccomandato) che la progettazione delle applicazioni si evolva nel tempo. È molto difficile indovinare in anticipo quali sono esattamente le cose di cui avrai bisogno alla fine, quindi è meglio iniziare in piccolo e crescere nel tempo. Le tue funzionalità guideranno il tuo design.

Esistono anche tecniche come lo sviluppo basato sui test che aiuteranno a migliorare l'architettura e il design generali.

Non dovresti ignorare il design in anticipo, ma fai attenzione a non tentare di ingegnerizzare il tutto subito. Man mano che acquisisci esperienza, migliorerai nel momento in cui sceglierai il design "giusto".

La linea di fondo è che devi avere una specifica funzionale di base prima di poter progettare qualsiasi cosa. Potresti pensare prima al design, ma cosa significherebbe? Cosa stai progettando? Supponiamo che tu abbia un'applicazione web che consente agli utenti di gestire i propri conti bancari. Ovviamente, hai bisogno di una sorta di database per raggiungere questo obiettivo. Probabilmente hai anche bisogno di una sorta di meccanismo di autenticazione sicuro. Questi sono requisiti funzionali di base che devono essere presenti prima di poter avere una discussione sul design. Altre cose come il layout della pagina o le funzioni che l'utente ha la possibilità di eseguire sono in gran parte dei punti muti in termini di architettura generale del sistema.

Direi che dovresti sempre avere una sorta di considerazione sul design nella parte posteriore della tua mente, ma devi sapere cosa stai facendo per prendere davvero delle decisioni importanti sul design.

I requisiti di progettazione seguono direttamente dai requisiti di funzionalità. Per determinare come saranno organizzati i componenti / le classi di un programma, è necessario per sapere qual è la funzionalità complessiva del programma e quali caratteristiche avrà. Una volta annullato, puoi decidere quale sia il design migliore per l'implementazione di tale funzionalità.

Potrebbe essere il caso in cui crei un disegno e, dopo aver determinato la funzionalità, devi rifare il tuo disegno, il che è un lavoro superfluo.

D'altra parte, è utile pensare a quale tipo di design potrebbe essere il migliore e sicuramente buttare giù alcune idee, ma rimanderei qualsiasi implementazione fino a quando non saprai con certezza quale sia il modo migliore di implementare.

Potrebbe essere un problema di pollo / uovo, ma se non hai funzionalità, non puoi progettare nulla: non sai cosa vuoi fare, perché, dove, come, ecc.

Quindi il primo avvio dovrebbe sempre essere la funzionalità. Non puoi iniziare con "hmm, sarà blu", e poi pensare. Ok, cosa farebbe il mio codice blu?.

Inizierebbe con "Sto costruendo un concetto che salverebbe la collezione di dvd degli utenti per un facile reperimento". Quindi potresti iniziare a pensare a qualche disegno prima di specificare se è necessario salvare il codice a barre dei tuoi dvd. Ma quel minimo di funzionalità sarà il primo.

Dovresti pensare al design fin dall'inizio. Ciò è particolarmente vero per l'utilizzo delle strutture dati e l'architettura generale dell'applicazione.

Tuttavia, è estremamente utile, in un contesto agile, realizzare prototipi funzionali e ottenere feedback dal cliente man mano che si sviluppano. Ciò assicura che tu e il cliente siano allineati ai tuoi obiettivi e ti offre alcune attività pratiche per assistere il processo di progettazione.

Probabilmente sta descrivendo un approccio agile allo sviluppo del software. Si fa solo l'analisi e la progettazione necessarie, quindi si scrive codice per creare un sistema che può essere effettivamente eseguito. In base a ciò ottieni ulteriori requisiti, progettazione, refactoring e ulteriori funzionalità.

Ad ogni passaggio il sistema è in uno stato funzionante ed è leggermente più avanzato.

Di solito, quando si tratta di specifiche di funzionalità ci sono due scenari:

1. Si specifica la piena funzionalità prima che inizia l'implementazione. Ciò significa che progetterai dopo specificando;
2. Definisci una specifica di alto livello, che evolve durante il progetto. In questo modo, definisci un design di alto livello prima di iniziare e poi raffina il progetto durante il progetto.

Esiste un terzo scenario, che prevede che i requisiti si presentino magicamente durante il progetto, ma non entriamo nel merito: -)

Quindi, il tema comune qui è che sì, fai specifica prima di progettare, anche se si tratta di una specifica di alto livello. Progettare prima specificando la funzionalità è pericoloso, poiché rischi di arrivare a un progetto che non modella accuratamente il problema che vuoi risolvere (o, peggio ancora, sovrascrivilo e usa un cannone per schiacciare una mosca ).

Devi trovare ciò che funzionerà per te nel tuo ambiente. Ti suggerisco di iniziare con un prototipo che potresti dover riscrivere, quindi progettare il sistema e implementarlo. Ripeti tutte le volte necessarie.

L'atto di programmazione è l'atto del design. Se hai scritto un codice, il tuo programma ha già un design. In effetti, il codice è il design. Non appena lo capisci, capirai perché la domanda è strana.

In altre parole, se hai già delle funzionalità, allora hai già un design.