Como você organizar sua biblioteca de código?
-
21-08-2019 - |
Pergunta
Estou interessado em saber como as pessoas organizam suas bibliotecas de código, particularmente com respeito a componentes reutilizáveis. Eu estou falando em termos OO abaixo, mas estou interessado em saber como o seu organizar bibliotecas para outros tipos de linguagem também.
Por exemplo:
- Você é um defensor de projetos de biblioteca de classe para tudo ou você prefere manter tudo em um único projeto?
- Você reutilizar suas DLLs pré-construídos ou você incluem aulas individuais de projetos anteriores em seu trabalho atual? Se aulas individuais, você compartilhá-los entre os projetos para garantir que todos são mantidos atualizados ou você permitem ramificação?
- Como são grandes os seus elementos reutilizáveis? Como focado são eles? Como eles estão focadas?
- Qual o nível de reutilização que você alcançar através de suas práticas preferidas?
etc.
Editar
Eu não estou procurando orientação específica aqui, estou apenas interessado em pensamentos e práticas das pessoas. Estou particularmente interessado na reutilização de código entre projetos diferentes, ao invés de dentro de um único projeto. (Infelizmente, a utilização de 'projecto' aqui é enganosa -. I reutilização média entre projetos reais desenvolvidos para os clientes, e não projetos em um sentido Visual Studio)
Solução
De modo geral, pode ser guia de implantação considerações:
Como é que vai implantar (ou seja, o que você vai copiar em sua máquina de produção)?
Se o que você está implantando são embalados componentes (ou seja, dll, jar, guerra, ...), é sábio para organizar a "biblioteca de código" como uma coleção de embalados conjunto de arquivos.
Dessa forma, você irá desenvolver diretamente com o - dll, jar, guerra, ... -., Que será implantado na plataforma de produção
A idéia é:. Se ele trabalha com os arquivos embalados, pode ainda trabalho na produção
a reutilização de código entre projetos diferentes, ao invés de dentro de um único projeto.
I manter esse tipo de reutilização é mais fácil em uma abordagem de "componente" (como o discutido na pergunta " Ramos fornecedor no GIT ")
Ao longo de mais de 40 projetos atuais, conseguimos:
- reutilização técnico isolando sistematicamente qualquer aspecto puramente técnica no quadro independente (normalmente, o quadro de log, o quadro de exceção, KPI - Key Performance Indicator - quadro, e assim por diante).
Esses componentes técnicos são reutilizados em todos os outros projectos. - reutilização funcional , definindo uma clara aplicativo arquitetura, a fim de dividir qualquer domínio funcional (dada a negócios e especificações funcionais) em aplicações bem definidas. Que normalmente envolvem, por exemplo, uma camada de ônibus que também é um grande candidato para expor serviços reutilizados por outros projectos.
Resumo:
Para grande domínio funcional, um único projeto não ser administrável, uma boa arquitetura aplicativo levará a reutilização de código natural.
Outras dicas
Nós seguimos estes princípios:
- O Release-Reuse Equivalência Princípio:. O grânulo de reutilização é o grânulo de libertação
- O Princípio fecho comum:. As classes em um pacote deve ser fechado em conjunto contra os mesmos tipos de alterações
- The Common Princípio Reuse:. As classes em um pacote são reutilizados juntos
- O Acíclica Dependências Princípio:. Permitir há ciclos no gráfico pacote de dependência
- The Stable Dependência Princípio:. Depend na direção da estabilidade
- The Stable Abstraction Princípio:. Um pacote deve ser tão abstrato como é estável
O que quer que você decide bom controle de código fonte é crucial para isso, pois permite-lhe implementar sua estratégia de qualquer maneira que você gosta sem acabar com lotes de cópias não relacionados de sua libraries.good ramificação apoio é essencial.