Siempre trato de seguir el principio DRY estrictamente en el trabajo; cada vez que repito el código por pereza, lo morderá más tarde cuando necesito mantener ese código en dos lugares.
Pero a menudo escribo pequeños métodos (tal vez de 10 a 15 líneas de código) que deben reutilizarse en dos proyectos que no pueden hacer referencia entre sí. El método podría ser algo que ver con redes / cadenas / MVVM, etc. y es un método generalmente útil no específico para el proyecto en el que se encuentra originalmente.
La forma estándar de reutilizar este código sería crear un proyecto independiente para el código reutilizable y hacer referencia a ese proyecto cuando lo necesite. El problema con esto es que terminamos en uno de los dos escenarios menos que ideales:
- Terminamos con decenas / cientos de pequeños proyectos, cada uno para albergar las pequeñas clases / métodos que necesitamos reutilizar. ¿Vale la pena crear un nuevo
.DLL
solo para un poco de código? - Terminamos con un solo proyecto que contiene una creciente colección de clases y métodos no relacionados. Este enfoque es para lo que hizo una empresa para la que trabajaba; tenían un proyecto llamado
base.common
que tenía carpetas para cosas como las que mencioné anteriormente: redes, manipulación de cadenas, MVVM, etc. Fue increíblemente útil, pero hacer referencia a él arrastra innecesariamente todo el código irrelevante que no necesitabas. li>
Así que mi pregunta es:
¿Cuál es la mejor manera de hacer que un equipo de software reutilice pequeños fragmentos de código entre proyectos?
Me interesa especialmente si alguien ha trabajado en una empresa que tiene políticas en esta área, o si ha enfrentado este dilema personalmente como yo.
nota: mi uso de las palabras "Proyecto", "Solución" y "Referencia" provienen de un fondo en el desarrollo de .NET en Visual Studio. Pero estoy seguro de que este problema es independiente del idioma y la plataforma.