Devo racchiudere le strutture dati della libreria?

2

Supponendo che ho i seguenti oggetti (pseudocode per Ruby):

  • StringToXML con call metodo che accetta un String e restituisce un oggetto ExternalLibrary::XML::Document (una struttura dati da una libreria di terze parti)
  • XMLToArray con call metodo che accetta ExternalLibrary::XML::Document e restituisce un array seguendo alcune specifiche

Dovrei avvolgere ExternalLibrary::XML::Document in una struttura di dati del wrapper, come XMLDocument e passarlo invece? Qual è il vantaggio nel farlo?

    
posta Fire-Dragon-DoL 12.12.2017 - 22:52
fonte

2 risposte

5

A mio parere, il bilanciamento dipende da quanto è possibile anticipare le esigenze di progettazione del software in anticipo rispetto a quanto bene la biblioteca le soddisfa in modo specifico.

    
risposta data 13.12.2017 - 00:20
fonte
4

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:

  1. 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.

  2. 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.

    
risposta data 12.12.2017 - 23:23
fonte

Leggi altre domande sui tag