Come evitare di riscrivere parti di un'applicazione

Sto lavorando in una società per un progetto per il loro reparto vendite. È il mio primo lavoro di programmazione professionale, ma sto programmando da solo e apprendo da anni. Parte del progetto prevede la raccolta di alcuni dati e la loro combinazione con l'input per produrre e rappresentare graficamente. Quindi salva i dati ... e così via. Quindi ho scritto il codice per questo in poco meno di un giorno. Il giorno dopo ho mostrato il mio supervisore del progetto, e gli è piaciuto, ma "e se avessimo questo", e volevo che aggiungessi qualcosa al grafico. Questo non è stato un grande cambiamento nell'aspetto o nella funzione del programma, ma ha drasticamente cambiato il modo in cui dovevo archiviare i dati, elaborarli, ecc.

Ancora una volta, mi ci è voluto circa un giorno per ri-strutturare la tabella del database e riscrivere il codice praticamente da zero per supportare questa nuova richiesta. Gliel'ho riportato di nuovo e è successa esattamente la stessa cosa. Ha richiesto qualcos'altro che ha drasticamente cambiato il modo in cui avevo bisogno di elaborare i dati. Quindi, ho dovuto riscriverlo di nuovo. Alla fine ha firmato e, spero, non dovrò riscriverlo di nuovo.

Sii chiaro, non sto colpendo il mio manager o qualcosa del genere. È un ragazzo eccezionale e le cose che chiedeva non erano fuori dal mondo, erano solo incompatibili con quello che avevo fatto in precedenza.

Mi chiedo solo se c'è qualcosa che posso fare in futuro per evitare riscritture complete. Comprendo la creazione di un codice flessibile e stavo cercando di farlo, ma vorrei solo sapere di eventuali pratiche o cose che avrei potuto fare in modo diverso per rendere questo più facile, quindi, in futuro, non spendo 3 giorni in qualcosa che avrebbe dovuto prendere 1.

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

Non tutto può essere affrontato con codice migliore, migliori pratiche, modelli di progettazione o principi OOP. Nessuno di questi ti impedirà di ripetere l'intera applicazione se l'implementazione si basa su presupposti falsi o premesse errate.

Non abbiate fretta nel codificare la soluzione. Prima di scrivere un singolo LOC, dedicare del tempo a chiarire i requisiti. Quanto più approfondisci i requisiti, tanto più se compaiono delle domande. Non aspettare che il Manager ti sorprenda con il successivo what-if . Anticipare le cose da soli. Questo piccolo esercizio può ridurre significativamente il fattore sorpresa .

Non abbiate paura di chiedere tutte le volte che è necessario. A volte gli alberi (dettagli) non ci permettono di vedere la foresta (il quadro generale). Ed è la foresta che dobbiamo prima vedere.

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

Infine, ricorda che il quadro generale è un obiettivo. Il percorso per raggiungere questo obiettivo non è né semplice né diretto. I cambiamenti continueranno ad accadere, quindi sii agile.

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

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 capacità di usare buoni principi di programmazione e buoni progetti. I programmatori adorano riscrivere, ancora e ancora . Non sto dicendo che cadi in questo necessariamente perché, in questo momento, è piccolo.

Utilizzare questa opportunità per applicare alcuni principi di base. Scoprirai che funzionano, ma poi qualcuno dirà "Oh no, non va bene" o farai qualcos'altro che ti piace. Non puoi fare tutto con i soldi dell'azienda, ma se ti danno il tempo di esplorare, usalo come un'opportunità. C'è sempre qualcuno, qualche fondazione, qualche persona che ha il modo "migliore" o un modo "nuovo" di fare le cose.

Molto probabilmente il tuo manager ha avuto ragione in ciascuno dei passaggi che hai superato. Non è perché è il manager, ma perché sta prendendo in considerazione i risultati e l'usabilità e probabilmente il numero di precedenti rapporti con clienti o richieste dei clienti.

L'interfaccia utente è roba difficile, di solito 5 persone hanno 15 visualizzazioni diverse. E i dati e la strutturazione dei dati e l'analisi dei dati tendono a cambiare questo moltiplicarsi per il fattore 10 :). L'interfaccia utente è come la moda, alcune combinazioni sono fantastiche, alcune sono terribili o mancano di buon senso.

Per non parlare del fatto che, ad esempio, durante il processo LEAN nulla è impresso nella pietra. Stai vivendo qualcosa di simile alla valutazione iterativa e durante ogni passaggio è leggermente migliore o si evita il percorso sbagliato.

La risposta è così semplice, che non esiste affatto una riscrittura.

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

All'inizio di un progetto, impari a convivere con le versioni apparentemente instabili. Non sarò d'accordo con le risposte che affermano che "devi ottenere più requisiti in anticipo", perché è il pensiero di Waterfall. È vero che dovresti cercare di ottenere il massimo in termini di requisiti, ma per molte ragioni non è possibile avere requisiti completi e precisi.

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

Pensa a Microsoft Word e al modo in cui il suo formato di 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 si è evoluta in lotti (e continua a farlo). Il codice per la presentazione o l'input tende a essere instabile tra le versioni, quindi è meglio non accoppiare direttamente le altre parti del sistema (per isolarle dalla riscrittura).

Le architetture software in grado di separare la presentazione dalla logica e dai dati sottostanti sul problema consentono una minore riscrittura. Molti modelli software come la separazione di Model-View sono nati a causa di persone come te che hanno sofferto per molte riscritture e hanno cercato un modo migliore.

Può sembrare molto buddista, ma sei fortunato ad aver subito queste riscritture! Così tante persone conoscono i modelli MVC o altri modelli di progettazione senza "soffrire" gli incubi di riscrittura che i modelli dovrebbero evitare.

Non ho una risposta, tanto quanto un esercizio - uno 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.

Riprogetta la tua prima soluzione per fare esattamente quello che ha fatto, ma semplifica l'aggiunta del 2o, 2o e 3o passaggio. Non aggiungere questi passaggi, non cancellarli. Basta creare una soluzione che soddisfi tutti i requisiti originali ma che possa essere facilmente aggiornata per includere la nuova funzionalità. Fai lo stesso per la tua seconda soluzione.

I requisiti cambiano, questo è un dato di fatto. Con il senno di poi: la prima soluzione avrebbe potuto essere diversa, quindi il tempo totale di programmazione sarebbe stato inferiore? Ecco cosa impari a fare con l'esperienza.

Questa è la prima curva di apprendimento ripida. Quando lo gestirai, ci sarà la seconda sfida: come gestirai i requisiti modificati quando gli utenti hanno archiviato un anno di dati che non vogliono buttare via?

Dalla tua storia è ovvio che i requisiti e le decisioni architettoniche preferite non sono stati comunicati abbastanza bene. Quindi uno di voi, o forse entrambi, sono cattivi comunicatori.

Potrebbe anche essere l'architetto, poiché alcuni architetti guadagnano il loro status elevato per buoni risultati quando programmano da soli, o una grande istruzione (che è anche il più delle volte studiando da soli) o essendo il primo sviluppatore dell'azienda (ovviamente solo) e sono non necessario bene nel comunicare con la squadra. Non è raro che continuino a concentrarsi pesantemente sulla programmazione piuttosto che sulla documentazione dei progetti e sul supporto del team.

Tuttavia anche in questo caso potresti provare a compensare parlando più a lungo, facendo domande e prendendo appunti. Puoi anche scrivere una piccola specifica e chiedere all'architetto di approvarla.