¿Cómo lidiar con la filosofía de reutilización de código?

Constantemente me encuentro pensando en la reutilización de código al comenzar un nuevo proyecto.

¿En qué medida debo hacer que mi código sea reutilizable?
¿Debería limitarlo al alcance de la aplicación o debería hacerlo reutilizable fuera del proyecto?

A veces, siento que la reutilización del código puede obstaculizar un diseño simple. Por favor, comparta su propia comprensión y enfoque de la reutilización del código.

El código tiene que funcionar antes de que pueda reutilizarse. Eso implica que el diseño y la función (primaria) deben venir antes de considerar la reutilización del código.

Es bueno estar pensando en reutilizar y reutilizar componentes que ya ha escrito. Pero a veces puede ser igual de rápido, si no más rápido, solo escribir el código y hacerlo funcionar. Después de resolver el problema original, puede refactorizar el código para hacerlo más reutilizable.

Recuerda el KISS y YAGNI:

Codifique re-usability better to be considereduna vez que tenga listo su documento de diseño . Esto le permitirá ver la sección / partes del código que posiblemente se duplicarán.

Por lo tanto, cuando no tenga un diseño claro, ¡aplique el enfoque KISS y YAGNI en su trabajo!

Esto es por mi experiencia, pero todavía creo que se puede aplicar y sigue la línea de lo que GlenH7 mencionó.

Trabajo entre 3 empresas haciendo varios proyectos. Las empresas son hermanas entre sí con algunas prácticas estándar y metodología de trabajo, pero también son únicas en muchos sentidos. Dicho esto, generalmente comienzo cada proyecto de nuevo y quiero terminarlo o mostrar progreso. Luego, si me encuentro con un escenario en el que recuerdo un fragmento de código o funcionalidad que escribí para un proyecto anterior, haré una de dos cosas (dependiendo del tiempo):

1. Método más rápido
   Copie el código anterior del otro proyecto (no tengo mucho tiempo) en mi proyecto actual.

2. Segundo método más rápido
   Copie el código anterior y colóquelo en una biblioteca común, luego incluya esa biblioteca en el proyecto actual (para facilitar el avance).

   2b. Si hago cambios en el otro proyecto (original), lo refactorizaré para usar la nueva biblioteca [pero generalmente no lo haré a menos que tenga que volver a tocar ese proyecto].

Solo se advirtió, prueba el demonio de las bibliotecas comunes. Las bibliotecas comunes significan crear dependencias. Las dependencias crean puntos de falla. Aunque es posible que necesite algo modificado ligeramente para su implementación actual, no sabe cómo va a cambiar nada más usando esa biblioteca.

A veces encuentro que copiar y pegar algunas líneas de código es una mejor solución. Incluso en lenguaje humano, cuando quieras decir una oración que dijiste antes solo con una ligera variación, la repetirás con la variación, ya que causa menos problemas a cualquiera.

Sin embargo, si su módulo grande necesita usarse de una manera ligeramente diferente que no es compatible, no lo clone solo para modificar algunas líneas porque es muy probable que desee ampliar la funcionalidad que tanto la base como el Clon compartir en el futuro. En cambio, simplemente configúrelo o exporte la funcionalidad que tanto la base como el clon comparten en otro módulo que ambos usarán.

No te excedas. Y si no está seguro, quédese con el alcance de la aplicación hasta que haya escrito suficientes proyectos para ver dónde puede reutilizar qué.