È comune che aggiunte apparentemente di piccole dimensioni comportino il cambiamento di molte funzioni?

2

Ho scritto un calcolatore binario & programma di insegnamento binario nel linguaggio di programmazione Rust. Stavo prendendo un approccio iterativo in cui ho deciso di iniziare per prima cosa un gioco base "learn binary". Questo gioco visualizza un numero esadecimale o decimale nella console e richiede al giocatore di inserire il numero in binari 1s e 0s come mezzo per aiutare gli studenti ad imparare il binario.

Ho quindi deciso di aggiungere funzionalità di calcolatrice binaria al programma creando una schermata di benvenuto e un menu in cui l'utente seleziona tra 1. Learn Binary 2. Binary Calculator e 3. Exit.

Ho quindi implementato la funzionalità del Calcolatore Binario.

Tuttavia, dopo averlo fatto, mi sono reso conto che all'interno del mio modulo di Calcolatore Binario mancava un'opzione "torna al menu principale", quindi una volta che un utente ha inserito la calcolatrice, lui / lei avrebbe dovuto uscire completamente dal programma per ottenere al gioco Learn Binary e viceversa.

Tuttavia, al fine di implementare una funzionalità di "ritorno al menu", mi sto rendendo conto che ora devo astrarre un loop out nella funzione principale o una funzione in basso, e ora ogni funzione in successione deve restituire alcuni dati in modo che questo ciclo possa sapere quando uscire. Sto finendo per dover cambiare e aggiungere diversi tipi di ritorno alle funzioni che stanno avendo un effetto domino e che richiede più tempo del previsto.

Questo è solo un piccolo esempio, ma mi trovo spesso ad affrontare questo genere di cose - è tipico dell'ingegneria del software? È normale dover tornare indietro e cambiare un sacco di cose quando vengono aggiunte nuove funzionalità o è un'idea migliore per pensare a tutto questo tipo di cose in anticipo?

Si noti che il mio programma è in gran parte procedurale ma usa un paio di costrutti OOP come necessario.

    
posta the_endian 01.12.2018 - 07:53
fonte

1 risposta

7

Sì, è normale.

La saggezza convenzionale di questi tempi è che nel complesso è più efficiente costruire prima ciò che è necessario, senza prima considerare le tutte conseguenze su tutte possibili caratteristiche o requisiti successivi. Ciò significa che sei disposto a rivedere alcune decisioni di progettazione che hai preso in precedenza (e ti senti a tuo agio nel fare tali cambiamenti senza timore di regressione perché la tua funzionalità è verificata semiautomaticamente da un'ampia suite di test).

Pensare prima alla progettazione globale di tutti i moduli probabilmente ti avrebbe risparmiato questa deviazione, ma pensare in anticipo ai problemi si rivela sorprendentemente difficile in generale - di solito è più facile scoprire cosa ti serve al punto X se Ho già progredito per indicare X-1. Pertanto, c'è un compromesso tra il costo della pianificazione in anticipo (passare il tempo a considerare molte alternative, la maggior parte delle quali non vengono mai costruite) e il costo di precipitare in avanti (richiedendo lavoro aggiuntivo per cambiare le decisioni di progettazione che sarebbero state più economiche da sistemare) in precedenza). Probabilmente hai sentito le parole "agile" e "cascata". Questo è esattamente ciò di cui tratta questo trade-off.

    
risposta data 01.12.2018 - 08:10
fonte

Leggi altre domande sui tag