Eu li muitas coisas na Internet. É realmente difícil encontrar algo sobre a arquitetura de software JAVA. No entanto, a arquitetura de desenvolvimento de software é basicamente a mesma. Portanto, pesquisei muitos artigos sobre arquitetura de software em outras línguas na Internet. Aqui, novamente, deixe-me falar sobre minha visão sobre arquitetura de software, especialmente sobre arquitetura de projetos JAVA. Isso pode não estar correto, mas este é também o meu resumo dos últimos anos.
1. Tente não considerar a reutilização fora do projeto
Muitas pessoas pensam que é melhor melhorar a reutilização do software. No entanto, a situação real de cada projeto será diferente. Ao projetar um determinado módulo ou método no projeto, muita consideração da reutilização fora do projeto aumentará inevitavelmente o número. de projetos. A complexidade aumenta a sobrecarga do tempo de desenvolvimento. Algumas pessoas podem dizer que isso reduzirá o custo do próximo projeto. Qual é o próximo projeto? Quais são as necessidades? Quais são os fatores que influenciam em vários aspectos? Quem saberia de tudo isso neste momento. Se você realmente deseja reutilizar, você deve extrair as partes reutilizáveis após a conclusão do projeto, modificá-las e otimizá-las e usá-las como ativos reutilizáveis da empresa, em vez de ilusões no projeto atual. Considere a reutilização fora do projeto. Este é um erro comum cometido por muitos programadores que são novos no trabalho de software. Muitas vezes, quanto mais pensam sobre isso, mais o software que criam falha em atingir o efeito de design e não consegue completar funções básicas ou. processos lógicos de código. Muitos, as funções do programa não são perfeitas e assim por diante.
2. Verifique frequentemente a estrutura do projeto
A arquitetura do projeto geralmente é algo determinado antes do início da implementação do projeto e é um design geral. No entanto, neste momento, a compreensão dos requisitos do projeto e a estimativa da complexidade ainda estão numa fase inicial. Se a arquitetura não puder ser melhorada juntamente com a compreensão do projeto durante o processo de desenvolvimento do projeto, os membros do projeto irão inevitavelmente desenvolver o projeto de acordo com a arquitetura errada. Portanto, a arquitetura do projeto deve ser verificada frequentemente e as refatorações necessárias devem ser feitas.
3. Refatoração
Algumas pessoas dizem que depois de escrever tanto, revisar não é perda de tempo. Ele pode não ter pensado que uma tarde de refatoração poderia acelerar o desenvolvimento nos próximos meses. O tempo economizado é inimaginável. Além disso, através da refatoração, geralmente você pode pensar em métodos mais simples para substituir a implementação existente. Essa experiência também pode simplificar o desenvolvimento de outros módulos.
4. Evite integração excessiva e deixe que cada módulo faça apenas suas próprias tarefas.
Um exemplo comum de desenvolvimento de OA é que geralmente há muitas aprovações em sistemas de negócios, e muitas pessoas pensarão imediatamente em transformar as aprovações em um módulo universal. Não há problema com isso, mas o problema usual é que muitas pessoas colocam o processamento de negócios após a aprovação na lógica de negócios do módulo de aprovação. Na verdade, esses são os módulos de negócios de cada módulo de negócios, e a aprovação deve apenas. ser concluído assim que a aprovação for concluída. No entanto, quanto ao que fazer após a conclusão da aprovação, deixe o módulo que faz esse processo cuidar dele sozinho.
5. Evite ser excessivamente flexível
O design e o código nem sempre são tão flexíveis quanto possível. Um exemplo comum é que, ao usar genéricos, classes ou métodos podem operar em objetos diferentes. No entanto, na arquitetura de três camadas comumente usada em JAVA, se uma série de classes for originalmente destinada a operar em uma entidade específica, não há necessidade. para especificá-lo como um tipo genérico e, em seguida, especificá-lo para usar uma classe de entidade específica ao usá-lo. Isso parece supérfluo.
6. Reduza os recursos de cereja no bolo
Nenhuma atualização de página, efeitos de exibição mais legais, etc. são a cereja do bolo para o sistema de negócios. Se a interface de negócios for muito complicada por causa disso, ela trará uma série de problemas ao processamento de negócios. Em casos extremos, o processamento de negócios não pode. Não importa quão bonita seja a interface, ela é inútil quando você continua. Quando se trata de um conselho, considere os outros apenas se quiser garantir que o processo de negócios seja executado corretamente. Um pré-requisito para isso é a comunicação necessária com os usuários. Em outras palavras, os projetos implementados em JAVA focam no processamento de negócios. Somente quando o processamento de negócios é bem realizado é que a beleza da interface e o sentido visual do usuário podem ser levados em consideração.
7. Divida adequadamente
Isso é semelhante a 4. Tente reduzir ao máximo a complexidade de cada módulo e converta o trabalho mental em trabalho físico. Um exemplo comum é que um formulário geralmente tem as funções de adicionar, modificar, excluir e visualizar. No entanto, as três primeiras operações geralmente são realizadas apenas por pessoas em um determinado ponto de função, em um estado específico e com permissões específicas (talvez apenas na única interface do sistema). Porém, as operações de visualização serão distribuídas em todos os cantos do projeto. Se essas quatro operações forem colocadas na mesma interface, embora o número de interfaces possa ser reduzido, o que aumentará é a complexidade dessa interface. processado. Faça os julgamentos necessários para fazer configurações somente leitura para elementos de interface. O aumento na complexidade é exponencial e, se você dividir a visualização, a carga de trabalho será linear. maior que o anterior. É muito mais fácil transformá-lo em 10*10, e também pode ser componenteizado.
8. Mantenha uma boa comunicação com os clientes
Muitas pessoas não prestam atenção em manter a comunicação com os clientes. Muitos arquitetos acreditam que a comunicação e a comunicação com os clientes só são necessárias durante a fase de demanda do projeto. Este é um péssimo hábito, porque os requisitos do cliente mudam com o tempo. no ambiente. Somente mantendo uma boa comunicação regular com os clientes podemos entender as mudanças nas necessidades dos clientes o mais rápido possível, ajustando assim nosso plano de estrutura de projeto para atender às necessidades dos clientes no menor tempo possível.
9. A conexão entre arquitetura de projeto e arquitetura de banco de dados
Muitas pessoas acreditam que um banco de dados não é necessário durante o desenvolvimento do projeto, desde que esteja implementado na memória. Pessoalmente, acho que este é um péssimo hábito de desenvolvimento. Embora o banco de dados seja determinado de acordo com as necessidades específicas do projeto. No entanto, se um projeto não considerar a arquitetura do banco de dados durante o processo de arquitetura, é provável que as coisas implementadas no projeto sejam difíceis de registrar no banco de dados ou o design do banco de dados seja muito problemático, o que aumentará virtualmente o dificuldade de desenvolvimento do projeto. Além disso, não considerar o banco de dados durante o processo de desenvolvimento do projeto pode causar problemas como falha na implementação de alguma lógica de negócio, perda de dados, etc. após o projeto ser vinculado ao banco de dados.
É claro que muitas pessoas têm opiniões arquitetônicas diferentes com base em seus diferentes estilos arquitetônicos, e minha opinião pode não estar correta. Espero que todos possam aprender algo com o meu trabalho e também espero que todos possam compartilhar suas opiniões sobre arquitetura.