Sono stato codificato per un bel po 'e ho trovato un progetto su cui voglio lavorare: un'applicazione web Python che utilizza django + mongodb.
So cosa voglio che faccia la mia app web. Quando sei in questa circostanza (solo iniziando un nuovo progetto) da dove parti? Cosa scrivi per primo? Codifica prima le viste?
Spero che non sia stato chiesto prima (ho dato una rapida occhiata), ma potrei usare un po 'di direzione generale.
È meglio iniziare con il tuo modello. I controller si baseranno sul modello e quindi si effettueranno le visualizzazioni per accedere ai controller.
UI / View logic dovrebbe sempre essere l'ultima cosa su cui lavori, dato che può cambiare quando i dati cambiano, ma se si progetta il modello per primo, si sta lavorando usando un approccio bottom-up, quindi quando si raggiunge il tuo punto di vista, avrai tutto pronto e saprai come le tue visualizzazioni dovrebbero accedere ai dati.
Idealmente, farai dei test su ogni passaggio, in modo che quando raggiungi la tua vista, sai esattamente come continuerai a persistere e recuperando i tuoi dati.
La pratica dello sviluppo orientato al test "fuori-in" consiglia innanzitutto di codificare l'interfaccia utente, guidata da test in cui si esclude il back-end. Continui a lavorare sugli strati della tua applicazione in questo modo, testando (e codificando) ogni strato della cipolla finché non sei pronto a muoverti verso l'interno; il modello è in genere l'ultima cosa che scrivi.
Questo ha vantaggi e svantaggi. Avere un prototipo di UI funzionante che puoi mostrare ai clienti significa che puoi iterare rapidamente il design dell'interfaccia utente senza impantanarti nel modello di dati. Ti aiuta anche a mantenere l'interfaccia utente disgiunta dal modello e sembra incoraggiante avere un'interfaccia utente visibile all'inizio del processo di sviluppo.
D'altra parte, l'interfaccia utente è in genere molto più difficile da testare rispetto al modello. Richiede disciplina per ricordare di testare il codice del tuo modello a un livello inferiore e non affidarsi a test di accettazione fragili per tutti i test.
Suggerirei un approccio equilibrato, passando da stili esterni a quelli interni come è appropriato per la situazione attuale.
Leggi altre domande sui tag coding-standards mvc