Utilizzo di modelli diversi per funzioni simili

Sono l'unico sviluppatore di un progetto che, come per qualsiasi progetto software, potrebbe essere preso da qualcun altro in futuro.

Diciamo che ho usato il modello X per implementare la funzione A. Dopo aver sviluppato e finito la funzione, mi rendo conto di poter implementare la stessa funzione usando il modello Y, di cui ho appena appreso. Ma la funzione A funziona bene e il refactoring da X a Y richiede molto tempo e offre pochi vantaggi.

Quindi è il momento di implementare la funzione B. È simile ad A, ma questa volta voglio cogliere l'occasione per giocare con il modello Y. Sono contento del risultato finale, meglio di quando faccio la funzione A, ma ora il mio codice usa due diversi modelli, X e Y, per caratteristiche simili.

Ma non vi è alcun motivo reale per utilizzare modelli diversi, tranne per il fatto che durante la creazione della funzionalità AI non era abbastanza abile da utilizzare lo stesso modello della funzionalità B.

Si noti che questa domanda non riguarda la scelta del modello giusto per un determinato problema ; si tratta di due modelli che coesistono nella base di codice per risolvere problemi simili, che potrebbero essere ridotti a uno a cui è stato concesso il tempo sufficiente per il refactoring.

• Quel codice ha un odore?
• Quali sono gli svantaggi di mantenere il codice sorgente in questo modo?
• Dovrei attenermi all'utilizzo di un solo modello? cioè il refactor A per usare Y o continuare a usare X quando si scrive B?
• Come, nella fonte, posso comunicare che il motivo per cui esistono due diversi modelli per caratteristiche simili non è essenzialmente un motivo?
• Mi sto preoccupando troppo di ciò che il prossimo sviluppatore pensa del mio codice?

Se i pattern X e Y risolvono lo stesso problema e nessuno dei due è oggettivamente migliore, allora dovresti decidere su uno e attenerci ad esso. Se è possibile, dovresti cercare di risolvere lo stesso problema nello stesso modo in modo coerente.

Stai non preoccuparsi troppo, piuttosto si tratta di un codice di serio odore che si dovrebbe assolutamente gestire e ripulire.

Gli svantaggi di avere diverse soluzioni allo stesso problema in una base di codice:

• ci vorrà il doppio del tempo per capire il codice
• ci vorrà il doppio del tempo per modificare il codice quando si modifica parte del comportamento che coinvolge il modello
• avrai il doppio del numero di bug
• i colleghi attuali e futuri ti odieranno

Sono d'accordo con la risposta di JacquesB . Vorrei aggiungere, rispondendo ad altre tue domande, che se in questo momento hai i due schemi coesistenti e non hai avuto (ancora) il tempo di riformattare la tua applicazione per utilizzare quella che hai trovato essere la migliore, dovresti mettere che nei tuoi commenti nella classe "offensiva" (quella da refactoring). In questo modo, è evidente al futuro sviluppatore (tu o qualcun altro) che c'è ancora qualche debito da pagare.

Infine, il principale svantaggio di mantenere una base di codice come questa è la complessità aggiunta, ma non necessaria. Vuoi assolutamente evitare la complessità non necessaria a tutti i costi!

Non giocare nella base di codice. Scrivi prototipi per trovare i vantaggi e gli svantaggi di un modello / disegno rispetto agli altri.

Si può scoprire che ciò che si sente intuitivamente può essere ridotto, in realtà potrebbe essere più complesso di avere 2 modelli diversi.

Aspettatevi di gettare via gran parte del codice sviluppato per il prototipo.

Se questo è un odore di codice dipende davvero da quanto siano simili il problema A e il problema B. La risposta di JacquesB sembra presumere che siano molto simili e che se si modifica il problema A (ad esempio per correggere un bug), si dovrà anche cambiare il problema B contemporaneamente. JaqueB potrebbe avere ragione, ma potrebbe anche essere il caso che A e B cambino indipendentemente perché non sono poi così simili. In quella situazione è improbabile che vengano descritti gli aspetti negativi.

Sulla base della tua descrizione sembra un po 'un odore di codice (duplicazione) ma è difficile dire quanto sia puzzolente l'odore. Ad esempio, se A utilizza il metodo modello e B utilizza la strategia, i due problemi potrebbero essere molto diversi nonostante i modelli di mirroring utilizzati. Vorrei aspettare e vedere l'approccio. Nel caso in cui si verifichi il problema C ed è proprio come A e B, allora farei refactoring A per essere coerente con B e quindi creare C dovrebbe essere molto semplice. Se c'è un bug in A, vorrei anche riformattare in modo che corrisponda a B, quindi correggere il bug. Nel caso in cui nulla cambi quindi ... non importa, vero?

Avere molteplici modi per risolvere problemi simili in una base di codice è un dato di fatto. Anche nel caso in cui tu sia l'unico sviluppatore, imparerai nuove cose e avrai nuove intuizioni, quindi le tue soluzioni cambieranno. Quando riconosci correttamente, devi correggere queste imperfezioni fornendo valore. Riprogettare (che è quello che stai realmente facendo quando cambi uno schema) che non cambierà mai più non fornisce valore. L'unico vero modo per sapere che cambierà è in realtà dover effettuare il cambiamento, motivo per cui aspetterei un problema C.

No, puoi avere più pattern usati in una singola base di codice.

Tuttavia, se stai implementando un componente e stai esponendo un modo di usarlo che segue uno schema, probabilmente è meglio attenersi a quello. Supponiamo, ad esempio, che sto usando il modello di generatore per il mio client di query REST, ma poi implemento una delle risorse in modo diverso. Questo confonderà le persone.