Diciamo che ho creato un servizio di livello di logica aziendale (o un gestore nel modello Comando / Query) con un metodo DoSomething che elabora un gruppo di entità e le memorizza nel database.
Più tardi, un altro sviluppatore vede: "oh, questo metodo DoSomething fa quasi tutto ciò di cui ho bisogno, posso chiamarlo dal mio metodo DoThisSomethingAndMore ." Sembra la cosa giusta da fare per evitare di copiare il codice da DoSomething a DoThisSomethingAndMore . I test unitari passano, tutto è OK.
Quindi arriva un nuovo requisito aziendale per modificare l'operazione DoSomething . Quindi, cambio il codice di DoSomething , e quindi DoThisSomethingAndMore si rompe.
Se abbiamo buoni test, possiamo rilevarlo presto. Ma come risolvere il problema? Crea DoThisSomethingAndMore per non chiamare DoSomething e copia-incolla il codice, invece? Refactor DoSomething in pezzi che possono essere riutilizzati sia da DoSomething sia da DoThisSomethingAndMore ? Potrebbe trattarsi di una notevole quantità di lavoro, coinvolgendo tutti gli sviluppatori che chiamano DoSomething dal loro codice e si collegano a un numero ancora maggiore di codice che chiama altri metodi. Inoltre, questo potrebbe portare a una serie di metodi pubblici ( DoPart1OfSomething , DoPart2OfSomething ...) sulla classe di servizio del livello aziendale, quando questi metodi dovrebbero essere interni perché non eseguono effettivamente una singola operazione di business atomico ma solo una parte di esso.
Si tratta di un problema di programmazione comune e dovrebbe sempre essere risolto tramite refactoring o significa che dovremmo optare per il completo servizio aziendale e il disaccoppiamento delle operazioni, accettando che ciò comporterà una duplicazione del codice?
La voce interiore dice: rendere ogni sviluppatore responsabile solo del proprio codice nei metodi commerciali che ha creato e non chiamare i metodi degli altri quando si sa che, molto probabilmente, cambieranno la loro implementazione interna. Ciò sembra ragionevole considerando che il progetto è stato sviluppato da una società di startup con alcuni sviluppatori non esperti che trarrebbero vantaggio da una chiara "regola empirica" fin dall'inizio, invece di investigare ogni chiamata di metodo separatamente, e anche considerando che i requisiti aziendali stanno cambiando spesso durante le prime fasi di sviluppo.
E poi c'è un'altra voce interiore "hey, non duplicare il codice, riutilizzare il codice è una delle migliori pratiche".
Quindi, mentre mi piacerebbe andare con la singola responsabilità con l'approccio alla duplicazione del codice, non riesco a trovare una scusa ragionevole o solide basi per questo. C'è qualche? Sarebbe bello avere un riferimento ad alcune fonti attendibili (ad es. "La banda dei quattro") dicendo in quali casi la duplicazione del codice è generalmente accettabile.