Come faccio a creare un progetto SW maturo prima dell'implementazione stessa? E come faccio a far fronte alle modifiche?

Se il problema ha qualche complessità, non importa quanto tempo spendi per un progetto iniziale, dovrà cambiare quando inizi a scrivere il codice. Quindi non cerco nemmeno di produrre un disegno che copra ogni caso d'uso. Invece, progetto solo per un caso d'uso alla volta, e refactoring (riprogettazione) mentre implemento ogni caso d'uso successivo. Questa pratica ha prodotto il codice più elegante.

Ciò che mi aiuta nella progettazione del software è una carta comune e una matita. Per ottenere un'immagine più ampia, di solito disegno e visualizzo il problema che deve essere risolto. Avvio a livello globale e quindi separarlo in parti più dettagliate e più semplici in cui pseudo codice ad esempio può essere utile. È possibile ottenere una visione molto migliore dell'intero sistema e delle parti particolari che devono essere realizzate visualizzandole e "serializzandole" su carta. Ti aiuta anche a identificare la modularità o la complessità e quindi a prevedere i possibili miglioramenti o insidie futuri.

Inizia identificando i casi d'uso pianificati per il programma. Quindi attraversali uno per uno, rifletti sui passaggi necessari e concentrati su come il sistema dovrebbe fornire i risultati attesi. Questo ti aiuta a scoprire le entità chiave / concetti di dominio e, di conseguenza, gli oggetti nel sistema e le loro relazioni, assicurando che lavorino insieme in modo significativo e siano in grado di fornire ciò che ci si aspetta.

Aiuta a disegnare schizzi di oggetti interagenti durante il walk-through. Inizialmente gli schizzi a mano su un pezzo di carta o lavagna sono completamente adatti; più tardi, mentre il tuo progetto si solidifica, potresti volerlo convertire ad es. Diagrammi UML.

Se hai un reigh gratuito sul sistema che stai sviluppando, dovresti essere in grado di identificare le aree che potrebbero cambiare. Puoi incapsularli per dimostrare che hai comunque dei cambiamenti futuri del sistema. Potresti voler esaminare il modello di strategia per guidarti su questo, o se stai usando C #, puoi usare i delegati.

Per quanto riguarda la documentazione delle cose durante il ciclo di vita della defvelopment che cambia, è necessario ottenere un feedback costante dagli sviluppatori su cosa è cambiato e, soprattutto, PERCHÉ? Quindi rivedi la tua documentazione per mostrare questo, non sostituendo il tuo lavoro originale, ma con un addendum che spiega perché è cambiato. Questa è una curva di apprendimento chiave e qualcosa per cui il tuo professore dovrebbe premiarti.

Concentrati sulle tue funzioni pubbliche e le interfacce più all'inizio: come una classe interagirà con un'altra? Se i tuoi metodi pubblici continuano a cambiare frequentemente, risulteranno in molti cambiamenti in luoghi diversi, portando a maggiori probabilità che gli errori continuino. I metodi delle classi private possono cambiare in seguito senza farti male, ma i metodi pubblici dovrebbero rimanere il più stabili possibile. Questo ovviamente non significa che non cambi affatto i metodi pubblici, ma quando provi a minimizzare le possibilità che avrai di farlo ancora una volta.