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"?

26

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.

DrMistry
fonte
5
Se a equipe for externa, será difícil tentar mudar alguma coisa. Em vez de focar no problema, você está tentando promover sua ideia. O problema é "eles nem sempre nos enviam códigos atualizados", eles resolvem esse problema da maneira que preferem. Eles não podem conceder acesso ao sistema de controle de versão?
precisa saber é o seguinte
9
Parece bobagem. Os projetos não serão mais nem menos dependentes um do outro, seja em uma ou trinta soluções. O motivo para manter o código em soluções separadas é porque a biblioteca resultante é usada por várias construções implementáveis ​​separadas. Isso não soa como o seu caso.
22616 David Arno
3
Parece que você tem muitos problemas não técnicos que são melhor resolvidos por alterações em seu contrato e declarações de trabalho.
Ross Patterson
9
Criar uma solução única não significa necessariamente que eles precisam desistir das soluções individuais, pois um projeto pode existir em mais de uma solução.
Erik Eidt
6
Não sei por que você está se perguntando sobre soluções técnicas para algo que é essencialmente um problema de pessoas. Demita essas pessoas e contrate pessoas acima do nível medíocre de competência. Isso significa que você pagará mais, mas definitivamente vale a pena em TI em termos de custo total de propriedade reduzido. Quanto mais você aguentar, mais sofrerá.
Brad Thomas

Respostas:

54

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 .

Doc Brown
fonte
Sim, eu concordo que o F5 não é um processo de construção, mas queremos testar seu código na equipe de desenvolvimento antes de passar para o nosso processo de controle de qualidade para testes de ponta a ponta, devido às regressões e falhas na atualização. Como eu disse, não temos acesso ao seu TFS, portanto, precisamos importar as alterações para nossa própria base de código e depois fazer check-in no TFS. No momento, esse processo é tão ruim que executar a autobuild no check-in é uma total perda de tempo! Temos construção automática no restante de nossos produtos e funciona muito bem para nós.
DrMistry
Só queria acrescentar que o material "The Joel Test" é excelente e eu recomendo dar uma boa olhada. Muito obrigado!
DrMistry
3

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.

KeithN
fonte
Nenhum dos projetos divididos é usado em nenhum outro lugar, isso é frustrante. Eles são usados ​​neste único produto e em nenhum outro lugar!
DrMistry 4/16/16
1

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!

Dominic Cerisano
fonte
0

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.

Kasper van den Berg
fonte