¿Por qué un equipo de desarrollo insistiría en que el uso de una única solución para múltiples proyectos en Visual Studio "aumenta la complejidad de la interdependencia"?

Estoy ayudando a administrar un equipo externo que está comenzando a desarrollar nuevas versiones de algunos productos existentes. Históricamente, este equipo siempre ha utilizado un modelo de un solo proyecto en una única solución para aproximadamente 30 módulos en Visual Studio que se unen para producir una compilación desplegable.

Esto está teniendo un impacto negativo en la confiabilidad y calidad de la construcción, porque no siempre nos envían el código fuente más actualizado. Estamos tratando de presionarlos para unificar todo el código referenciado en una única solución, pero estamos obteniendo cierta resistencia, específicamente siguen hablando de que aumenta la interdependencia entre módulos (lea "proyectos" en Visual Studio) si todo se coloca en Un único archivo de solución. Ninguno de los códigos en las soluciones separadas se usa en otros lugares.

Insisto, esto no tiene sentido y los buenos patrones de desarrollo evitarán cualquier problema.

El equipo en cuestión también realiza la corrección de errores y el desarrollo de nuevas características en un producto existente, cuya experiencia ha sido difícil de decir y sufre exactamente el mismo problema de dividirse en múltiples soluciones. Se nos ha negado el acceso a su control de fuente ( TFS ), y el enfoque que estamos adoptando para unificar la base de código es intentar y al menos reducir el número de actualizaciones faltantes y más que regresiones ocasionales (sí, los errores corregidos se están volviendo a generar -introducido en el producto) diciendo "envíenos un ZIP de la carpeta de solución completa para que podamos descomprimirlo, abrirlo en Visual Studio y presionarF5 para pruebas ". En términos de estructura general y calidad, el código es bastante pobre y difícil de soportar. Esta experiencia es la razón por la que tengo la intención de hacer que los procesos de trabajo sean lo más temprano posible en el ciclo de desarrollo.

¿Se me escapa algo? ¿Alguna vez hay una buena razón para mantener todo ese código separado? Por mi dinero, tendría que ser una razón tan convincente que sería de conocimiento común, pero estoy más que dispuesto a admitir que no lo sé todo.

No necesita decirles cómo estructurar sus proyectos. En cambio, haga un requisito difícil que pueda construir el sistema desde la fuente ejecutando un solo script, sin obtener ningún error. Si esos scripts ejecutan Visual Studio o Msbuild u otras herramientas, y si se llaman una vez, 50 o 100 veces no deberían importar.

De esa manera, obtienes la misma "prueba de integridad" del código que obtendrías al poner todo en una única solución. Por supuesto, ese script no le dice si el equipo realmente ha revisado la última versión de su control de origen, pero tener el código completo en una solución tampoco lo verificaría.

Como respuesta a "la interdependencia entre los módulos se incrementa si todo se coloca en un único archivo de solución" - esto es una tontería demostrable , ya que agregar proyectos a una solución no cambia ninguna de las dependencias entre proyectos, las dependencias son el resultado de un proyecto archivo que hace referencia a otro, que es completamente independiente de qué solución hace referencia a qué archivo de proyecto. Nadie detiene a ese equipo para tener ambos: una única solución que hace referencia a todos los proyectos, y también soluciones individuales, cada una de las cuales hace referencia a un solo proyecto.

Sin embargo, sugeriría agregar un script de compilación. Esto tiene beneficios incluso cuando solo hay un archivo de solución. Por ejemplo, le permite a uno ejecutar una compilación VS con una configuración preferida, le permite copiar los archivos finales para la implementación (y nada más) a una carpeta de "implementación", y puede ejecutar algunas otras herramientas y pasos para completar la compilación. ¡Vea también que F5 no es un proceso de construcción! y The Joel Test .

Dependería de cuánto se reutilicen los ensamblados compilados. Si no hay reutilización de ensamblajes, entonces no hay una razón real para mantener los "módulos" separados. De hecho, en mi experiencia, esto es más un obstáculo.

En el equipo de desarrollo del que formo parte, tenemos bibliotecas independientes que hemos escrito que se utilizan en varios productos como una solución separada, lo que en este caso tiene sentido de lo contrario tendríamos que compilar la Aplicación A para mantener la Aplicación B actualizada, que puede ser necesario para mantener actualizada la Aplicación C

Cada producto se mantiene en su propia solución, incluso si hay varios proyectos que lo componen. De esta forma, solo tenemos que construir la solución de la Biblioteca para mantener actualizado su código compartido en todos los productos desarrollados.

Cada compañía de software para la que trabajé tenía un equipo de desarrollo central que proporcionaba la sucursal principal que cubría los casos de uso fundacional de los productos de la compañía.

Los desarrolladores de sucursales que usan el repositorio principal son responsables de descubrir mejoras y enviar solicitudes de extracción a la sucursal principal para su revisión. Por lo general, así es como uno se convierte en un desarrollador principal, al mostrar que puede hacer mejores contribuciones que simplemente avivar las llamas de un conflicto arquitectónico.

Es probable que su empresa simplemente no tenga los recursos para "unificar todo el código referenciado de forma inmediata". Sugerir que lo hagan sin comprender sus limitaciones presupuestarias es (como mínimo) probable que evite que uno se convierta en un ingeniero central.

¡Así que formule su gran visión en unas pocas solicitudes de atracción devastadoras hasta el núcleo, y prepárese para defenderse en la revisión!

Hay un núcleo de verdad en la afirmación "El uso de una solución única para múltiples proyectos aumenta la complejidad de la interdependencia".

Una solución única hace que sea más fácil hacer referencia a un proyecto de otro proyecto (es decir, reutilizar el código de un proyecto, también conocido como "introducir complejidad de interdependencia")

• en lugar de examinar todo el sistema de archivos / caché de ensamblado global para el ensamblado al que se hace referencia, puede seleccionar el proyecto de un conjunto limitado de proyectos relevantes en la solución; y,
• Al leer el código fuente, es mucho más fácil saltar a un proyecto referenciado en la solución que a un ensamblaje arbitrario (binario).

Por lo tanto, en manos de un equipo indisciplinado que utiliza múltiples proyectos en una sola solución puede generar muchas dependencias introducidas de forma descuidada. Sin embargo, un equipo puede tratar mejor de aprender la disciplina necesaria para administrar cuidadosamente las dependencias y luego usar la facilidad de reutilización que ofrece el uso de soluciones.