Quale tecnica di modellazione usi per il tuo design continuo? [chiuso]

Chiamiamo una sessione di progettazione ogni volta che qualcuno di noi si sente incerto su come implementare una nuova funzione / refactoring. O anche se pensiamo di avere chiaramente un'idea (approssimativa), ma il problema è abbastanza complesso da non essere completamente supervisionato da tutto.

Nel primo caso, è ovvio che beneficiamo di discutere insieme il problema e di ottenere pensieri, suggerimenti e critiche dagli altri. Nel secondo caso è ancora vero che più occhi ci sono per verificare il design approssimativo, meglio è. Ma anche se il progetto risulta essere "perfetto" (che praticamente non accade mai nella vita reale), è comunque utile condividere la comprensione comune del problema specifico e della sua soluzione all'interno del team. Ciò aiuta a mantenere la visione architettonica coerente nell'intero team.

Usiamo abbozzi UML ruvidi, ma non carte CRC btw.

Per come la vedo io, costruire un programma complesso è come costruire una casa. Come costruisci una casa? Bene, devi disegnare i progetti, creare il telaio di legno, installare le tubazioni, installare elettricità, coprire il telaio, posare la piastrellatura per i pavimenti, ecc. Affrontare un programma complesso senza comprendere correttamente tutto ciò che farà è come costruire un casa senza sapere quante stanze costruire. Potresti finire per costruire un muro che finirai per dover abbattere perché devi aggiungere un'altra stanza. Peggio ancora, forse dovresti strappare completamente il pavimento per dirigere i tubi nella nuova stanza perché sarà un bagno.

Sfortunatamente, non sapendo quante stanze hai intenzione di costruire è abbastanza normale nella progettazione del programma, ea volte ciò non può essere aiutato. Tuttavia, un buon approccio alla progettazione di un programma complesso con questa idea in mente è quello di costruire uno scheletro che ti limiti in tutti i modi in cui ti aspetteresti un piccolo cambiamento (crea un'interfaccia per accedere al database per esempio, dato che sai che sei andando ad accedere ad alcuni database ad un certo punto nel tuo programma). Spendi un bel po 'di sforzo nello scheletro e le future modifiche saranno facili, dal momento che hai previsto la possibilità di tale cambiamento. Piuttosto che abbattere muri più tardi, tornare alla mia metafora, non hai mai costruito un muro perché c'era la possibilità di estendere quella stanza.

Detto questo, è impossibile anticipare ogni cambiamento e non è possibile creare un programma senza impegnarsi in qualche cambiamento, quindi è sufficiente esperienza per sapere come affrontare al meglio la creazione di un programma.

Stai scrivendo un codice per un particolare sistema, che ha un flusso da eseguire. È fondamentale capire perché stiamo progettando, per noi stessi, decisamente no. Il design non è fatto per noi stessi, è per l'utente, chi userà il sistema, programmerà il sistema, manterrà il sistema. Se vogliamo capire il sistema nella prospettiva dell'utente, il suo design sarà sicuramente diverso da un progetto realizzato per il programmatore del sistema. Scegli lo strumento di conseguenza che soddisfi i requisiti del particolare utente.

Uso un mix di metodi:

1. Incontro di design. Pro, hai fissato un ordine del giorno e, si spera, ottieni un accordo coerente sulla direzione del design. Con, costoso in termini di tempo e persone.
2. Accoppia la programmazione. Pro, condivide conoscenza, due teste incentrate su un problema. Le truffe, sprecate per codice boilerplate e simili, possono essere difficili da giustificare per la gestione.
3. Prototyping. Io prototipo estensivamente, scrivo due volte di più, eseguo il deployment una volta, ti consente di capire dove sono i punti problematici senza commetterlo.
4. refactoring. Legami davvero con la prototipazione, ma progetta il tuo software secondo buoni principi (SOLID per esempio) e il refactoring diventa più facile permettendoti di risolvere i problemi.