La dimensione e la complessità del codebase sono in aumento per renderla completamente configurabile?

Non esiste una regola dura e veloce. Ma questa domanda dovrebbe sempre essere considerata attentamente quando si pensa di riprogettare un sistema.

In generale, è una pratica molto scorretta codificare tutte le impostazioni nel programma. Le impostazioni di configurazione e i grandi valori esterni dovrebbero sempre provenire da file. Questa separazione di dati e codice (o logica) dovrebbe, per qualsiasi applicazione di dimensioni ragionevoli, rendere il tuo codice più leggibile e gestibile.

In generale, questo dovrebbe essere un obiettivo dall'inizio. Se ti trovi, come in questo caso, con una base di codice disordinata con valori hard-coded sparsi in giro, allora devi considerare attentamente se refactoring il modo "corretto" vale il costo. Il refactoring di un'applicazione esistente richiede tempo e non offre alcun beneficio immediato agli utenti finali (o al datore di lavoro).

Anche se può sembrare brutto avere un codice brutto come questo, in una situazione di vita reale, spesso non si ha il lusso di lucidare il codice nella misura in cui ci si sente a proprio agio. Solo una volta che la manutenibilità del codice diventa un ostacolo a ulteriori sforzi di sviluppo, spesso un refattore ne vale la pena.

In questo caso, è la tua app, quindi hai il controllo completo. Inoltre, hai già inserito il lavoro per la riscrittura, quindi congratulazioni! Tuttavia, il tuo codice non dovrebbe essere più complesso rispetto a prima:

I've noticed my codebase is nearly 3x the size and feels much more complex than it did earlier.

L'aumento delle dimensioni è previsto, ma ciò che intendi per "complesso" è importante lì. Trovi il codice più difficile da ragionare e navigare? Se è così, questa è una grande bandiera rossa, come hai scritto tu stesso tutto il codice! Immagina se sei entrato come nuovo sviluppatore in un'azienda e dovresti iniziare a lavorare su questo codice base. Pensi che lo troverai facile o difficile?

D'altra parte, se per "complesso" intendi semplicemente che c'è più logica in corso, ma lo capisci ancora bene, allora è meno preoccupante. Se aggiungi più funzionalità a un'applicazione, sta andando a essere più parti mobili. Ma la qualità complessiva del codice in tutta l'applicazione dovrebbe rimanere più o meno la stessa.

Sembra che tu stia pesando il costo del codice che è un po 'più difficile da capire rispetto al codice originale contro il vantaggio di poter "scambiare, aggiungere o rimuovere colonne da fogli di calcolo o database senza interrompere il comportamento dei programmi" , così come le ottimizzazioni che accelerano le cose fino a (fino a) un fattore di 10 (e forse di più?). Solo tu puoi veramente rispondere se ne valga la pena, ma se le prestazioni e le funzionalità migliorate sono qualcosa che ti piace più di un codice di facile lettura (ma che richiede molto tempo per mantenerle), allora ne valeva la pena.

E se sei preoccupato che la tua base di codice più elaborata sia più difficile da capire, allora davvero vuoi iniziare a documentarla ADESSO, prima di dimenticare come funziona.

Hai apportato le modifiche in base ai requisiti specifici degli utenti finali?

• Se sì, è importante che gli utenti abbiano questa modifica.
• Se no, hai ritenuto che un "comportamento completamente configurabile" fosse davvero auspicabile per qualsiasi prevedibile futuro requisito che sicuramente implementerai?
  • Se sì, "forse" è degno di cambiamenti futuri. Ho detto "forse" perché puoi solo dire se per ora è degno, considerando la complessità aggiunta.
  • Se no, ti è piaciuto o hai imparato qualcosa di nuovo mentre implementavi le modifiche?
    • Se sì, solo tu puoi dire se è degno o meno.
    • Se no, potrebbe valere alcuni punti reputazione su stackexchange:)