Ci sono casi eccezionali in cui possiamo accettare il codice duplicato?

La duplicazione può essere la cosa giusta da fare, ma non per questo motivo.

Dicendo "potremmo volere che questi tre punti nella base del codice si comportino diversamente anche se in questo momento sono identici" non è una buona ragione per la duplicazione su larga scala. Questa nozione potrebbe applicarsi a ogni sistema e potrebbe essere utilizzata per giustificare qualsiasi duplicazione, che ovviamente non è ragionevole.

La duplicazione dovrebbe essere tollerata solo quando la sua rimozione sarebbe complessivamente più costosa ora per qualche altra ragione (non si può pensare a una buona ora, ma si può essere sicuri che ce ne possa essere una - praticamente tutto in programmazione è un trade-off piuttosto che una legge).

Per quello che stai facendo, la soluzione giusta potrebbe essere ad es. estraendo il comportamento che è stato duplicato in questo momento in una strategia o in un altro modello che modella il comportamento come classi e quindi utilizza tre istanze della stessa classe. In questo modo, quando fai vuoi modificare il comportamento in uno dei tre punti, devi solo creare una nuova strategia e creare un'istanza in un unico punto. In questo modo devi solo aggiungere alcune classi e lasciare il resto del codice base quasi completamente intatto.

Sandi Metz, rinomato software engineer e autore nell'ecosistema Ruby, ha un ottimo post del blog e un talk dove parla anche della relazione tra la duplicazione e astrazione. Arriva alla seguente conclusione

duplication is far cheaper than the wrong abstraction

E sono completamente d'accordo con lei. Lascia che ti dia più contesto a questa citazione. A volte trovare la giusta astrazione è molto difficile. In questi casi si è tentati di usare l'astrazione qualsiasi per ridurre la duplicazione. Ma più tardi potresti scoprire che la tua astrazione non vale per tutti i casi. Tuttavia, è costoso cambiare di nuovo tutto e seguire una strada diversa (per una spiegazione molto migliore guardala!).

Quindi sì, per me, ci sono casi eccezionali, in cui accettare la duplicazione è la decisione giusta, specialmente quando non si è sicuri di cosa accadrà e i requisiti potrebbero cambiare. Dal tuo post prendo atto che ora c'è molta duplicazione, ma i tuoi colleghi suggeriscono che questo potrebbe cambiare e non accoppiare entrambe le applicazioni l'una all'altra. A mio avviso questo è un argomento valido e non può essere ignorato in generale.

Se le persone iniziano a ragionare sul design con le parole "se domani" , questo è spesso un grande segnale di avvertimento per me, specialmente quando l'argomento viene usato per giustificare una decisione che include lavoro e sforzo extra , per il quale nessuno sa davvero se questo sarà mai ripagato, e che è più difficile da cambiare o annullare rispetto alla decisione opposta.

La duplicazione del codice riduce lo sforzo solo per un breve periodo, ma aumenterà gli sforzi di manutenzione quasi immediatamente, proporzionale al numero di linee di codice duplicate. Nota anche che una volta che il codice è duplicato, diventa difficile rimuovere la duplicazione quando si scopre che questa è stata la decisione sbagliata, mentre se non si duplica il codice ora, è ancora facile introdurre la duplicazione in un secondo momento se si scopre che si attacca a DRY è stata la decisione sbagliata.

Ha detto che, nelle organizzazioni più grandi, a volte è vantaggioso favorire l'indipendenza di diversi team rispetto al principio DRY. Se si rimuove la duplicazione estraendo le parti comuni delle API del 95% due componenti nuovi portano a un accoppiamento di due team altrimenti indipendenti, questa potrebbe non essere la decisione più saggia. D'altra parte, se disponi di risorse limitate e ci sarà un solo team che gestisce entrambe le API, sono sicuro che sarà nel loro stesso interesse non creare alcun doppio sforzo ed evitare inutili duplicazioni di codice.

Nota ulteriormente fa la differenza se le API "Home" e "Agency" sono utilizzate esclusivamente da applicazioni completamente diverse, o se si potrebbe provare a scrivere una build di componenti su quelle API che possono essere utilizzate in una "Home" contesto così come in un contesto di "Agenzia". Per questa situazione, avere le parti comuni delle API esattamente identiche (che puoi garantire solo se le parti comuni non sono duplicate), renderà probabilmente molto più semplice lo sviluppo di tale componente.

Quindi, se risultasse che ci saranno squadre secondarie davvero diverse, ognuna responsabile per ciascuna delle API, ognuna con una pianificazione e risorse diverse, allora è il momento di duplicare il codice, ma non "nel caso" .

Duplicazione per impedire l'accoppiamento . Diciamo che hai due grandi sistemi e li costringi ad usare la stessa libreria. Potresti accoppiare il ciclo di rilascio di entrambi i sistemi. Questo potrebbe non essere un problema, ma diciamo che un sistema deve introdurre un cambiamento. L'altro ha bisogno di analizzare il cambiamento e potrebbe essere interessato. A volte può rompere le cose. Anche se entrambe le parti sono in grado di coordinare i cambiamenti, potrebbero esserci molti incontri, passando per i manager, i test, le dipendenze e la fine del piccolo team autonomo.

Quindi stai pagando il prezzo del codice duplicato per ottenere autonomia e indipendenza.