Ninguém mais mencionou a faca de dois gumes ainda, então vou adicionar meus 2 centavos. Se você possui vários projetos e todos compartilham algum código reutilizável, de acordo com as boas práticas / princípios de programação (DRY, por exemplo), coloque o código em um local global e estruture-o de maneira a que possa ser compartilhado por todos seus projetos sem modificações. Em outras palavras, defina as interfaces como genéricas e comuns o suficiente para atender a todos.
Existem poucas opções para fazer isso: 1) Crie um projeto base do qual os outros dependem. Este projeto pode criar uma distribuição binária que outros projetos consomem. 2) Puxe um modelo de código aberto dentro da sua organização. Faça com que o código comum seja sua própria ramificação de código e faça com que outros projetos obtenham código da mesma maneira que você usaria o código-fonte de qualquer OSS online.
Agora é aqui que a espada entra ...
Colocar o código em um local comum do qual outros projetos / pessoas dependem pode se tornar bastante caro. Digamos que você tenha um pedaço de código e 4 outros projetos dependam dele. Um de seus clientes que usa o projeto A encontra um erro e é necessário fazer uma correção. Você apressa a solução e esse cliente está feliz. Mas você acabou de modificar algum código do qual outros 3 projetos dependem. Você testou novamente tudo isso para garantir que nenhuma condição de borda foi introduzida?
O código comum também deve ser criado com muito mais cuidado e as interfaces do módulo devem ser muito melhor projetadas, porque esse código deve acomodar não um, mas quatro clientes e cada um deles pode apenas usar esse código com uma diferença tão pequena.
Se seus projetos estão em diferentes ciclos de lançamento, você precisa ter ainda mais cuidado com o gerenciamento do código comum. Você não pode simplesmente fazer alterações no código comum porque o projeto B precisa de nova funcionalidade, se você estiver a três dias de cortar a imagem final do projeto C.
Não estou dizendo que biblioteca comum não é a solução certa. Sou um forte apoiador do DRY e já criei e apoiei códigos comuns antes e continuo a fazê-lo. Só queria divulgar que simplesmente tornar o código comum terá suas próprias despesas.
Se você é o único reutilizando esse código, isso não é tão ruim. Se você tem uma equipe de engenheiros e eles começam a usar o código comum, as despesas aumentam ainda mais. Se houver outras pessoas envolvidas, espere que a inserção de código em uma biblioteca comum leve três vezes mais tempo que o necessário para chegar a um ponto em que você acha que está "completo". Você precisará: a) tornar a biblioteca mais robusta para proteger contra todos os tipos de condições de borda e uso inválido, b) fornecer documentação para que outros possam usar a biblioteca ec) ajudar outras pessoas a depurar quando usarem a biblioteca de uma maneira que você não antecipou e sua documentação não cobriu o caso de uso específico.
Algumas sugestões que posso oferecer:
- Ter um código comum coberto por testes de unidade automatizados pode percorrer um longo caminho e lembrar que, quando você faz uma alteração, não acaba apenas com outro projeto.
- Eu colocaria apenas funcionalidades muito estáveis no código comum. Se você escreveu uma turma no ano passado para gerenciar o cronômetro e não a mudou em 9 meses, e agora tem outros 3 projetos que precisam de cronômetros, certifique-se de que seja um bom candidato. Mas se você acabou de escrever algo na semana passada, bem ... você não tem muitas opções (e eu odeio copiar / colar código provavelmente mais que o próximo), mas eu pensaria duas vezes antes de torná-lo comum.
- Se parte do código é trivial, mas você já o usou em vários lugares, talvez seja melhor morder a bala, deixe o DRY em paz e deixe várias cópias ao vivo.
- Às vezes, vale a pena não simplesmente colocar o código comum em um local comum e fazer com que todos o façam referência. Mas, em vez disso, trate o código comum como seu próprio liberável com versões, datas de lançamento e tudo mais. Dessa forma, o projeto C pode dizer: "Eu uso a biblioteca comum v1.3" e, se o projeto D precisar de novas funcionalidades, você deixa a v1.3 em paz, libera a v1.4 e o projeto C não é afetado. Lembre-se de que é MUITO, MUITO mais caro tratar o código comum como seu próprio produto, em vez de simplesmente fazer o check-in em um local comum.