Por que uma equipe de desenvolvimento insistiria que o uso de uma solução única para vários projetos no Visual Studio "aumenta a complexidade da interdependência"?

Estou ajudando a gerenciar uma equipe externa que está começando a desenvolver novas versões de alguns produtos existentes. Historicamente, essa equipe sempre usou o modelo de um único projeto em uma única solução para cerca de 30 módulos no Visual Studio que se unem para produzir uma compilação implementável.

Isso está afetando negativamente a confiabilidade e a qualidade da compilação, porque elas nem sempre nos enviam o código-fonte mais atualizado. Estamos tentando pressioná-los para unificar todo o código referenciado em uma única solução, mas estamos obtendo alguma resistência - especificamente eles continuam falando sobre a interdependência entre os módulos (leia-se "projetos" no Visual Studio) aumentando se tudo for colocado em um único arquivo de solução. Nenhum código nas soluções separadas é usado em outro lugar.

Insisto que isso não faz sentido e que bons padrões de desenvolvimento evitarão esse problema.

A equipe em questão também realiza correções de bugs e desenvolvimento de novos recursos em um produto existente, cuja experiência foi difícil para dizer o mínimo e sofre exatamente o mesmo problema de se dividir em várias soluções. Foi-nos recusado o acesso ao seu controle de origem ( TFS ), e a abordagem que estamos adotando para unificar a base de código é tentar e pelo menos reduzir o número de atualizações ausentes e mais do que regressões ocasionais (sim, os bugs corrigidos estão sendo recuperados). - introduzido no produto) dizendo "envie-nos um ZIP de toda a pasta da solução para que possamos descompactar, abra-o no Visual Studio e pressioneF5 para testes ". Em termos de estrutura geral e qualidade, o código é muito ruim e difícil de suportar. Essa experiência é a razão pela qual pretendo acertar os processos de trabalho o mais cedo possível no ciclo de desenvolvimento.

Tem algo que estou perdendo? Existe alguma boa razão para manter todo esse código separado? Para o meu dinheiro, teria que ser uma razão tão convincente que seria de conhecimento comum, mas estou mais do que disposto a admitir que não sei tudo.

Você não precisa dizer a eles como estruturar seus projetos. Em vez disso, torne um requisito difícil que você possa construir o sistema a partir da origem executando um único script, sem obter erros. Se esses scripts executam o Visual Studio ou Msbuild ou algumas outras ferramentas, e se esses são chamados uma vez, 50 ou 100 vezes não devem importar.

Dessa forma, você obtém o mesmo "teste de integridade" do código que obteria colocando tudo em uma única solução. Obviamente, esse script não informa se a equipe realmente fez o check-out da versão mais recente em seu controle de origem, mas ter o código inteiro em uma solução também não verificaria isso.

Como resposta à "interdependência entre módulos sendo aumentada se tudo for colocado em um único arquivo de solução" - isso é um absurdo comprovável , pois a adição de projetos a uma solução não altera nenhuma das dependências entre os projetos, as dependências são o resultado de um projeto arquivo referenciando outro, que é completamente independente de qual solução faz referência a qual arquivo de projeto. Ninguém impede que a equipe tenha os dois - uma solução única que faz referência a todos os projetos e também soluções individuais, cada uma referenciando apenas um projeto.

No entanto, eu sugeriria adicionar um script de construção. Isso tem benefícios mesmo quando há apenas um arquivo de solução. Por exemplo, ele permite executar uma compilação VS com uma configuração preferida, permite copiar os arquivos finais para implantação (e nada mais) em uma pasta "deploy" e pode executar outras ferramentas e etapas para concluir a compilação. Veja também F5 não é um processo de compilação! e O teste Joel .

Isso dependeria de quanto os conjuntos compilados são reutilizados. Se não houver reutilização de montagens, não haverá motivo real para manter os "módulos" separados. De fato, na minha experiência, isso é mais um obstáculo.

Na equipe de desenvolvimento de que faço parte, temos bibliotecas independentes que escrevemos usadas em vários produtos como uma solução separada. Nesse caso, faz sentido caso contrário, teríamos que compilar o Aplicativo A para manter o Aplicativo B atualizado, que pode ser necessário para manter o aplicativo C atualizado.

Cada produto é mantido em sua própria solução, mesmo se houver vários projetos que o compõem. Dessa forma, só precisamos criar a solução Library para manter seu código compartilhado atualizado em todos os produtos desenvolvidos.

Todas as empresas de software em que trabalhei tinham uma equipe de desenvolvimento principal que fornecia o ramo principal que cobre os casos de uso fundamentais dos produtos da empresa.

Os desenvolvedores de filial que usam o repositório principal são responsáveis ​​por descobrir melhorias e enviar solicitações pull ao ramo principal para revisão. Geralmente, é assim que alguém se torna um desenvolvedor central, mostrando que é possível fazer contribuições melhores do que apenas acender as chamas de um conflito arquitetural.

É provável que sua empresa simplesmente não tenha os recursos para "unificar imediatamente todo o código referenciado em uma única solução". Sugerir que façam isso sem entender suas restrições orçamentárias (pelo menos) provavelmente impedirá que alguém se torne um engenheiro central.

Portanto, formule sua grande visão em algumas solicitações devastadoras ao núcleo e prepare-se para se defender em revisão!

Há um núcleo de verdade na asserção "Usar uma solução única para vários projetos aumenta a complexidade da interdependência".

Uma única solução facilita a referência a um projeto de outro projeto (ou seja, a reutilização do código de um projeto conhecido como "introdução da complexidade da interdependência"):

• em vez de procurar em todo o sistema de arquivos / cache global de assemblies referenciados, você pode selecionar o projeto em um conjunto limitado de projetos relevantes na solução; e,
• ao ler o código-fonte, é muito mais fácil pular para um projeto referenciado na solução do que para um assembly arbitrário (binário).

Portanto, nas mãos de uma equipe indisciplinada, o uso de vários projetos em uma única solução pode levar a muitas dependências introduzidas de forma descuidada. No entanto, uma equipe pode tentar aprender a disciplina necessária para gerenciar cuidadosamente as dependências e depois usar a facilidade de reutilização oferecida pelas soluções.