In realtà, dipende.
Per prendere l'esempio XML, considera quanto potrebbe essere necessario il refactoring se fosse necessario estendere o modificare il codice per utilizzare oggetti rappresentati da un formato diverso; per esempio, non sarebbe più bello se il tuo codice non fosse interessato se si trattasse di JSON, XML, Protobufs, ecc?
D'altro canto, devi pesare il costo (in fase di sviluppo iniziale e nella creazione di un ulteriore livello di riferimento indiretto) di scrivere un ulteriore livello di astrazione rispetto al potenziale beneficio e probabilità di dover supportare altri formati di dati.
Inoltre, considera i test unitari, ad esempio quanto è facile usare la libreria con i test unitari? Nel caso dell'XML, è generalmente facile scrivere alcuni dati XML fittizi o fornire un file XML fittizio. Nel caso più generale, si potrebbe prendere in considerazione la scrittura di un livello di astrazione se è probabile che la libreria interferisca con il test (ad esempio, se richiede un endpoint remoto o un dispositivo hardware per funzionare correttamente).
Se non c'è un impatto significativo sui test e non puoi prevedere alcuna necessità di aggiungere quel tipo di indirezione, allora considera YAGNI princple , ma mira anche a strutturare almeno il codice in modo tale da ridurre al minimo l'impatto del futuro refactoring nel caso in cui sia necessario un nuovo livello di astrazione in seguito.
In definitiva si tratta di costi iniziali rispetto ai costi futuri previsti. Ci sono davvero due scenari:
-
Il costo di scrittura di un codice più complesso in anticipo implica una spesa più lunga nella scrittura di quel codice, e potrebbe coinvolgere gli sviluppatori futuri che hanno difficoltà a imparare come funziona il codice, ma potrebbe anche risparmiare tempo a implementare i requisiti futuri.
-
Il costo iniziale del lancio del codice nel più breve tempo possibile può essere ampiamente superato dalla necessità di rimborsare il tecnico Il debito in futuro, e nel caso estremo, rischia di creare un Big Ball of Mud .
Anche se non dovresti cadere nella trappola di scrivere soluzioni elaborate a problemi semplici, dovresti sempre cercare modi per ridurre al minimo il debito tecnico; spesso puoi ottenere questo risultato investendo tempo creando test automatici. Se stai lottando per decidere, forse un modo più utile per esaminare l'enigma è se la creazione di un nuovo livello di astrazione ridurrà il tempo necessario per scrivere quei test.