¿Hay casos excepcionales en los que podemos aceptar código duplicado?

La duplicación puede ser lo correcto, pero no por este motivo.

Decir "es posible que queramos que estos tres lugares en la base del código se comporten de manera diferente, aunque en este momento son idénticos" no es una buena razón para la duplicación a gran escala. Esta noción podría aplicarse a cada sistema, y podría usarse para justificar cualquier duplicación, lo que obviamente no es razonable.

la duplicación se debe tolerar solo cuando eliminarla sería, en general, más costoso ahora por alguna otra razón (no puedo pensar en una buena en este momento, pero tenga la seguridad de que puede haber una, prácticamente todo en la programación es una compensación en lugar de una ley).

Por lo que estás haciendo, la solución correcta podría ser, por ejemplo, extrayendo el comportamiento que se duplica ahora mismo en una Estrategia o algún otro patrón que modele el comportamiento como clases y luego use tres instancias de la misma clase. De esa manera, cuando do quiera cambiar el comportamiento en uno de los tres lugares, solo tiene que crear una nueva estrategia e instanciarla en un solo lugar. De esa manera, solo tiene que agregar algunas clases y dejar el resto de la base de código casi completamente intacta.

Sandi Metz, una renombrada ingeniera de software y autora del ecosistema Ruby, tiene un gran blog y una talk donde también habla sobre la relación entre la duplicación y la abstracción. Ella llega a la siguiente conclusión

  

la duplicación es mucho más barata que la abstracción incorrecta

Y estoy completamente de acuerdo con ella. Déjame darte más contexto a esta cita. A veces es muy difícil encontrar la abstracción correcta. En tales casos, es tentador ir solo por cualquier abstracción para reducir la duplicación. Pero luego puede que descubra que su abstracción no es válida para todos los casos. Sin embargo, es costoso cambiar todo de nuevo e ir por una ruta diferente (¡para una explicación mucho mejor, mire cómo habla!).

Sí, para mí, hay casos excepcionales, donde aceptar la duplicación es la decisión correcta, especialmente cuando no está seguro de lo que está por venir y es probable que los requisitos cambien. Desde su publicación, tomo que ahora hay mucha duplicación, pero sus colegas sugieren que esto podría cambiar y no juntar ambas aplicaciones entre sí. En mi opinión, este es un argumento válido y no se puede ignorar en general.

Si las personas comienzan a razonar sobre el diseño con las palabras "si mañana" , esto es a menudo una gran señal de advertencia para mí, especialmente cuando el argumento se usa para justificar una decisión que incluye trabajo y esfuerzo adicionales. , por lo que nadie sabe realmente si esto alguna vez valdrá la pena, y cuál es más difícil de cambiar o revertir que la decisión opuesta.

La duplicación de código reduce el esfuerzo solo a corto plazo, pero aumentará los esfuerzos de mantenimiento casi de manera proporcional al número de líneas de código duplicadas. Tenga en cuenta también que una vez que se duplica el código, será difícil eliminar la duplicación cuando resulta que fue una decisión equivocada, mientras que si uno no duplica el código ahora, aún es fácil introducir la duplicación más adelante si resulta que se mantiene en DRY Fue la decisión equivocada.

Dijo que, en organizaciones más grandes, a veces es beneficioso favorecer la independencia de los diferentes equipos sobre el principio DRY. Si al eliminar la duplicación al extraer el 95% de las partes comunes de las APIs dos, un nuevo componente conduce a un acoplamiento de dos equipos independientes, esta podría no ser la mejor decisión. Por otro lado, si tiene recursos limitados y solo habrá un equipo que mantenga ambas API, estoy seguro de que será en su propio interés no crear ningún esfuerzo doble y evitar cualquier duplicación de código innecesaria.

Además, tenga en cuenta que hace una diferencia si las API "Inicio" y "Agencia" son utilizadas exclusivamente por aplicaciones completamente diferentes, o si se puede intentar escribir una compilación de componentes sobre esas API que se pueden usar en un "Hogar" contexto, así como en un contexto de "Agencia". Para esta situación, tener las partes comunes de las API exactamente idénticas (que solo puede garantizar si las partes comunes no están duplicadas), facilitará mucho el desarrollo de dicho componente.

Entonces, si resulta que habrá subgrupos realmente diferentes, cada uno responsable de cada API, cada uno con un calendario y recursos diferentes, entonces es hora de duplicar el código, pero no "por si acaso" .

Duplicación para evitar el acoplamiento . Digamos que tienes dos grandes sistemas y los obligas a usar la misma biblioteca. Puede estar acoplando el ciclo de liberación de ambos sistemas. Puede que esto no sea tan malo, pero digamos que un sistema necesita introducir un cambio. El otro necesita analizar el cambio y puede verse afectado. A veces puede romper cosas. Incluso si ambas partes son capaces de coordinar los cambios, pueden ser muchas reuniones, pasando por gerentes, pruebas, dependencias y el final del pequeño equipo autónomo.

Por lo tanto, está pagando el precio del código duplicado para obtener autonomía e independencia.