Os problemas que surgem no processo de produção estão gradativamente recebendo a atenção da média e alta administração. Seja você um desenvolvedor ou arquiteto, você deve prestar bastante atenção aos itens a seguir para evitar situações embaraçosas no futuro. Você também pode usá-lo como uma nota de solução de problemas.
#1. Não externalize propriedades de configuração em arquivos de propriedades ou arquivos XML. Por exemplo, o número de encadeamentos usados pelo processamento em lote não está configurado para ser configurável no arquivo de propriedades. Seu programa em lote pode ser executado sem problemas, seja em um ambiente DEV ou em um ambiente UAT (User Acceptance Test), mas uma vez implantado no PROD, quando for usado como um programa multithread para processar conjuntos de dados maiores, uma IOException será lançada , seja por causa de diferentes versões do driver JDBC ou por causa do problema discutido no item 2. Se o número de threads puder ser configurado em um arquivo de propriedades, será muito fácil torná-lo um aplicativo de thread único. Não precisamos mais implantar e testar aplicativos repetidamente para resolver problemas. Este método também é adequado para configurar URL, servidor e número de porta, etc.
#2. O tamanho do conjunto de dados usado no teste é inadequado. Por exemplo, um cenário típico durante a produção é usar apenas 1 a 3 contas para teste, quando o número deveria ser de 1.000 a 2.000. Ao fazer testes de desempenho, os dados utilizados devem ser reais e não cortados. Os testes de desempenho que não estão próximos do ambiente real podem trazer problemas imprevisíveis de desempenho, expansão e multithreading. Somente testando o aplicativo com um conjunto de dados maior você poderá garantir que ele funcione corretamente e atenda aos SLAs (padrões de nível de serviço) para atributos não funcionais.
#3.Acredite ingenuamente que os serviços externos e internos chamados na aplicação são confiáveis e estão sempre disponíveis. Não permitir tempos limite e novas tentativas de chamadas de serviço afetará negativamente a estabilidade e o desempenho do aplicativo. É necessário testar adequadamente a interrupção do serviço. Isto é importante porque as aplicações atuais são, em sua maioria, distribuídas e orientadas a serviços, exigindo um grande número de serviços de rede. Solicitar incessantemente serviços indisponíveis pode prejudicar seu aplicativo. O balanceador de carga também precisa ser testado para garantir que está funcionando corretamente e manter cada nó equilibrado.
#4. Os requisitos mínimos de segurança não são seguidos. Conforme mencionado acima, os serviços de rede são onipresentes, tornando mais fácil para os hackers explorá-los para ataques de negação de serviço. Portanto, ao usar o Secure Sockets Layer, você deve concluir a verificação básica e realizar testes de penetração usando ferramentas como o Google skipfish. Um aplicativo inseguro não apenas ameaça sua própria estabilidade, mas também pode impactar negativamente a reputação de uma empresa devido a problemas de integridade de dados, como uma situação em que o cliente “A” pode visualizar os dados do cliente “B”.
#5.Sem testes de compatibilidade entre navegadores. Os aplicativos da web de hoje são, em sua maioria, aplicativos ricos de página única que usam a linguagem de programação JavaScript e estruturas como angular js. Para que o site que você construiu funcione perfeitamente em diferentes dispositivos e navegadores, você deve implementar um design correspondente. Portanto, para garantir que seu aplicativo funcione em todos os dispositivos e navegadores, ele deve ser testado quanto à compatibilidade.
#6.Não externalizar regras de negócios que podem mudar com frequência. Por exemplo, leis fiscais, requisitos governamentais ou relacionados à indústria, taxonomias, etc. Você pode usar um mecanismo como o Drools para processar regras de negócios, o que ajuda a externalizar essas regras de negócios, armazenando-as em um banco de dados ou no Excel. Depois que as empresas dominam essas regras de negócios, elas podem responder rapidamente às leis fiscais ou aos requisitos relacionados com alterações e testes mínimos.
#7. Os seguintes documentos não são fornecidos
Além do COS (Condições de Satisfação), formulário criado pelo MindMap, existem dois principais formulários de documentos no desenvolvimento ágil , 1 e 2.
#8.Não ter um plano adequado de recuperação de desastres e uma estratégia adequada de monitoramento e arquivamento do sistema. À medida que os prazos do projeto se aproximam, essas coisas muitas vezes são perdidas na pressa de implantar o projeto. Não ter o monitoramento adequado do sistema com Nagios e Splunk não apenas ameaça a estabilidade do seu aplicativo, mas também dificulta os diagnósticos atuais e esforços de melhoria futuros.
# 9. Não existe um design de coluna conveniente para a tabela de banco de dados , comocreate_datetm, update_datetm,created_by, updated_by e timestamp. Ele também não fornece colunas de registro de exclusão ordenada, como a coluna 'excluída' que pode receber 'Y' ou. 'N'. Ou você pode pegar a coluna 'record_status' de 'Ativo' ou 'Inativo'.
#10. Falha no desenvolvimento de um plano de retração adequado. Como resultado, quando o sistema falha, não há como restaurá-lo ao estado estável antes da implantação. Este plano precisa ser cuidadosamente considerado e assinado pela equipe relevante. Os planos incluem reverter para uma versão anterior do software, removendo todos os dados inseridos no banco de dados e todas as entradas no arquivo de propriedades.
#11. Falha no desenvolvimento de um plano de capacidade antes do início do projeto. Hoje, ao descrever os requisitos da plataforma, não basta dizer simplesmente “requer um computador Unix, um servidor de banco de dados Oracle e um servidor de aplicativos JBoss”. Sua solicitação deve ser precisa
O nº 12 abaixo vem de um comentário de "David DeCesare" de "java.dzone",
# 12. “Não use a melhor ferramenta para o trabalho.” Em muitos casos, os desenvolvedores usarão uma linguagem ou ferramenta que desejam aprender em um sistema de produção. Geralmente esta não é a melhor opção. Por exemplo, usar bancos de dados NoSQL para dados que já são realmente relacionais. Lembre-se, não importa qual ferramenta você adote, você precisará manter seu produto pelos próximos 3 a 5 anos (ou até mais).
#13. Falta de reservas de conhecimento suficientes em 16 áreas técnicas principais. Essas áreas incluem a identificação e correção de 1) “problemas de simultaneidade”, 2) problemas de transação e 3) problemas de desempenho. Em muitas entrevistas, contei com esses três aspectos do conhecimento para conseguir novos contratos.