Come progettare per consentire la revisione della logica futura? [chiuso]

0

Il tipico metodo di progettazione della programmazione che ho scelto è il seguente:

1. ID the problem and what's required
2. Make your program do something simple
3. Test it
4. Make your program do a little bit more
5. Repeat 2 until all the micro problems are solved by the program as a whole

Fondamentalmente, design incrementale. Quindi, tutti i pezzi possono essere suddivisi e ogni micro problema è risolto da una funzione di micro-problema; fa un ottimo lavoro con la coesione e riduce l'accoppiamento.

Poi, a volte in futuro, il programma si imbatte in un problema che è proprio come il problema su cui è costruito, ma richiede un piccolo extra. Quindi, direi aggiungere la funzionalità al programma, per compensare. Se, quando aggiungi questa funzionalità, la logica di lavoro già stabilita deve essere modificata per far funzionare la nuova funzionalità, all'improvviso sembra che tu stia scherzando con qualcosa che non dovresti.

Quindi, esiste un metodo di progettazione in cui ogni programma sviluppato con esso può essere aggiunto senza compromettere la logica di lavoro?

Esempio:

word = yes,no,"maybe,so"

oldCSVSplit(word, ",") -> {"yes", "no", "\"maybe", "so\""}
newCSVSplit(word, ",") -> {"yes", "no", "maybe,so"};

La funzione oldCSVSplit fa quello che dovrebbe, divisa in ",". Quindi, a volte in futuro, le virgole tra virgolette devono essere ignorate per ottenere correttamente le voci. L'aggiunta della funzionalità per ignorare le virgolette singole / doppie altererebbe gravemente la logica, con più if e assegni e persino uno stack per tenere traccia delle virgolette iniziali. È possibile evitare uno scenario del genere? Quale metodo può rendere tali aggiunte indolori e meno compromettenti per la logica di lavoro?

    
posta user2738698 12.03.2014 - 18:53
fonte

3 risposte

5

Non c'è modo di proteggersi da tutti i cambiamenti nei requisiti. Indipendentemente dal modo in cui disegni il tuo codice, sempre esiste un requisito che ti costringerà a modificare la funzionalità. Il tentativo di prevedere tutti i possibili cambiamenti è inutile e sconsiderato: finirai con un codice troppo generalizzato e troppo astratto, che pagherà un costo iniziale di complessità aumentata senza sapere con certezza che pagherà in seguito. Peggio ancora, dal momento che c'è sempre un cambiamento in cui il tuo codice non è protetto, non c'è limite a quanto puoi ingigantire il tuo codice.

Il meglio che puoi fare è un codice per l'attuale serie di requisiti e adattarsi al cambiamento. Se mantieni il tuo design modulare, anche se le nuove aggiunte richiedono una quantità significativa di rilavorazioni, sarai almeno abbastanza sicuro di non aver inavvertitamente rotto funzionalità completamente indipendenti. Una volta che sei stato bruciato da un particolare tipo di modifica, allora puoi rendere il tuo codice resistente ad altre modifiche dello stesso tipo. (Se è successo una volta, ci sono buone probabilità che accada di nuovo.)

    
risposta data 12.03.2014 - 19:58
fonte
0

So, is there a designing method where every program developed with it can be added onto without compromising working logic?

No. Come perfezionerai, cambierai necessariamente la logica esistente. Lo nascondi, lo oscuri o lo riscrivi.

    
risposta data 12.03.2014 - 19:44
fonte
0

Bene, direi che cambiare il software che è stato scritto prima è una parte abbastanza importante di ciò che riguarda la programmazione.

Scommetto che la maggior parte degli sviluppatori è pagata per mantenere, estendere e correggere i progetti brownfield piuttosto che quelli greenfield.

Se hai bisogno di ottenere un programma per gestire uno scenario che non è stato progettato per gestire, hai per cambiare qualcosa e non dovresti sentirti male.

Potrei aver frainteso il tuo post ma, a mio parere, sembra che tu non pratri TDD oppure, se lo fai, hai una sorta di arretrato.

Se il primo è vero, dovresti assolutamente esaminarlo. Se il secondo è vero, potresti volerlo leggere di nuovo.

Nel caso in cui non si sappia di cosa sto parlando, TDD in breve è:

  1. Scrivi un test che conferma che il software non può già fare ciò che vuoi che faccia
  2. Esegui il test e dovrebbe fallire
  3. Solo allora scrivi del codice, il meno possibile, per passare il test
  4. Se il test passa, bam, sei d'oro e puoi rifattorizzare il codice per renderlo più comprensibile / efficiente / bello. Un'ulteriore esecuzione del test confermerà che non hai infranto nulla durante il refactoring
  5. Se il test non passa, beh, sfortuna, dovrai capire perché. La buona notizia è che, se esegui test unitari giusti, il tuo test sarà piccolo e focalizzato abbastanza da rendere la ricerca del bug un gioco da ragazzi nella maggior parte dei casi, senza nemmeno ricorrere al debugger

Se hai sviluppato il tuo programma con questo approccio, testare che si divida ancora su virgole ma non se una virgola è tra due virgolette doppie è banale. Avrai test precedenti che ti dicono che il programma si comporta come originariamente previsto, oltre a nuovi test che ti dicono che può gestire le virgole tra virgolette doppie.

L'apprendimento di più su TDD è lasciato come esercizio per il lettore.

    
risposta data 12.03.2014 - 19:55
fonte

Leggi altre domande sui tag