Come evitare di riscrivere parti di un'applicazione

Come ho commentato, ho la netta sensazione che i requisiti non siano stati chiari la prima volta o che probabilmente manchi di alcuni dettagli importanti.

Non tutto può essere risolto con codice, best practice, modelli di progettazione o principi OOP migliori. Nessuno di questi ti impedirà di ripetere l'intera applicazione se l'implementazione è basata su presupposti errati o premesse sbagliate.

Non precipitarti a codificare la soluzione. Prima di digitare una singola LOC, dedica del tempo a chiarire i requisiti. Più approfondisci i requisiti, più le domande e se vengono visualizzate. Non aspettare che il Manager ti sorprenda con il prossimo what-if . Anticipa te stesso. Questo piccolo esercizio può ridurre significativamente il fattore di sorpresa .

Non aver paura di chiedere tutte le volte che ti serve. A volte gli alberi (dettagli) non ci permettono di vedere la foresta (l'immagine generale). Ed è la foresta che dobbiamo vedere prima.

Quando i requisiti sono chiari, è più facile prendere decisioni migliori durante la fase di progettazione.

Infine, ricorda che l'immagine complessiva è un obiettivo. Il percorso verso questo obiettivo non è né semplice né diretto. Le modifiche continueranno ad accadere, quindi sii agile.

Non c'è modo di saperlo in base a ciò che hai dato. È più veloce e sporco di quello che ti serviva in quel momento. Ma poi a qualcuno è piaciuto e sta diventando complicato, quindi ora stai iniziando a vedere che molti problemi non si mostrano fino a quando non si verifica la complessità. Ci sono così tante cose diverse che possono essere fatte è semplicemente schiacciante.

C'è il vecchio, "No Silver Bullet", ed è vero. Ancora una volta, non c'è modo di sapere cosa fare con le specifiche complete (o le migliori specifiche in corso per Agile) e la possibilità di usare buoni principi di programmazione e buoni progetti. I programmatori amano riscrivere, ripetutamente . Non sto dicendo che ci sei caduto in questo, necessariamente per questo, in questo momento, è piccolo.

Usa questa opportunità per applicare alcuni principi di base. Scoprirai che funzionano ma poi qualcuno dirà "Oh no, è male" o ti piacerà qualcos'altro. Non puoi fare tutto con i soldi della compagnia, ma se ti permettono di esplorare, usalo come un'opportunità. C'è sempre qualcuno, qualche fondamento, qualche persona, che ha il modo "migliore" o un modo "nuovo" di fare le cose.

Molto probabilmente il tuo manager aveva ragione in ciascuno dei passaggi che hai superato. Non è perché è il manager, ma perché sta considerando i risultati e l'usabilità e probabilmente il numero di precedenti accordi con le richieste dei clienti o dei clienti.

L'interfaccia utente è difficile, in genere 5 persone hanno 15 visualizzazioni diverse. E la strutturazione di dati e dati e l'analisi dei dati tendono a cambiare che moltiplicano per il fattore 10 :). L'interfaccia utente è come la moda, alcune combinazioni sono interessanti, alcune sono terribili o mancano di buon senso.

Per non parlare del fatto che, ad esempio, durante il processo LEAN, nulla è impostato su pietra. Stai sperimentando qualcosa di simile alla valutazione iterativa e durante ogni fase, è poco meglio o si evita il percorso sbagliato.

La risposta così semplice è che non esiste nulla di simile a nessuna riscrittura.

Non ho una risposta, tanto quanto un esercizio, che probabilmente dovrai fare nel tuo tempo libero, anche se, a seconda della tua organizzazione, potresti essere in grado di ottenere il permesso di farlo durante l'orario di lavoro .

Ridisegnare la prima soluzione per fare esattamente ciò che ha fatto, ma rendere più facile aggiungere il 2 ° o 2 ° e 3 ° passo. Non aggiungere questi passaggi, non spegnerli. È sufficiente creare una soluzione che soddisfi tutti i requisiti originali, ma può essere facilmente aggiornata per includere la nuova funzionalità. Fai lo stesso per la tua seconda soluzione.

Lo sviluppo iterativo (che è quello che hai fatto sostanzialmente, anche se le iterazioni di un giorno) è spesso così. I primi tentativi di soluzioni sono spesso imprecisi e, raccogliendo feedback, il sistema converge verso una soluzione. Prenderò in prestito la Figura 2.2 dal materiale per istruttori di Craig Larman per il suo libro Applicazione di UML e Design Patterns .

All'iniziodiunprogetto,impariaconvivereconleapparentiversioniinstabili.Nonsonod'accordoconlerispostechedicono"devi avere più requisiti presto", perché questo è il pensiero di Waterfall. È vero che dovresti cercare di ottenere quanto più possibile in termini di requisiti, ma per molte ragioni non è possibile avere requisiti completi e accurati.

Questo non vuol dire che non puoi ridurre quanto devi riscrivere dopo aver ricevuto il feedback. Una cosa che è stata spesso vera è che l'interazione uomo-computer del software è molto probabile che cambierà, perché è una parte difficile da ottenere correttamente la prima volta.

Pensa a Microsoft Word e al modo in cui il suo formato dei dati (.doc) non si è evoluto molto nel corso degli anni. Questo perché un documento di testo come dominio problematico non si è evoluto molto (una pagina è ancora una pagina, un paragrafo è ancora un paragrafo, ecc.). Tuttavia, l'interfaccia utente di Word ha evoluto i lotti (e continua a). Il codice per la presentazione o l'input tende ad essere instabile tra le versioni, quindi è meglio non avere le altre parti del sistema accoppiate direttamente a loro (per isolarle dalla riscrittura).

Le architetture software che possono separare la presentazione dalla logica sottostante e i dati relativi al problema consentono una minore riscrittura. Molti modelli software come Separazione modello-vista sono nati per colpa di persone come te -crive e cerca un modo migliore.

Questo può sembrare molto buddista, ma sei fortunato ad aver subito queste riscritture! Così tante persone apprendono modelli MVC o altri modelli di progettazione senza aver "sofferto" gli incubi di riscrittura che gli schemi dovrebbero evitare.