Simon Brown, um desenvolvedor, arquiteto e autor, considera que é preciso muito mais que bom código para ter um projeto de sucesso. Em sua aprensentação, Bom código não é suficiente (Inglês), Brown fala sobre os elementos necessários para um projeto ter sucesso, do design claro à documentação.
Brown considera que bom código é um bom começo, mas para ter um projeto de sucesso é necessário conhecer o que deve ser desenvolvido, o que será lançado e que isto funciona.
Para saber o que desenvolver, é necessário vários requisitos. Após o levantamento de requisitos, uma visão geral da arquitetura do software que representa o entendimento atual do produto a ser desenvolvido deve ser desenhada. Então o grande problema precisa ser decomposto em pequenas soluções mostrando os componentes, a interação entre eles, e os serviços a serem utilizados. Estimer o que pode ser feito e quanto tempo levará para ser implementado. Tudo isso, para determinar os requisitos para fazer estimativas deve levar apenas 1 ou 2 dias, de acordo com Brown. Isto não é trabalho para um homem só, isto precisa ser feito colaborativamente com todos os diretamente envolvidos.
Caso feito corretamente, uma leve arquitetura introduz então a estrutura - "quais são os componentes e como eles se comunicam", guias - "documentação de padrões, templates e princípios" - no projeto levando a consistência - ter uma "abordagem padrão para corrigir problemas comuns" e clareza - Os envolvidos sabem para onde estão indo porque viram a visão geral. Como contra exemplo, Brown menciona um projeto utilizando três soluções de persistência: Spring, EJB e Hibernate. Isto porque ninguém decidiu qual framework de persistência deveria ser utilizado.
A próxima etapa é priorizar. A menos que seja um projeto pequeno, não se deve tentar gerar e lançar todo o projeto em uma etapa, mas em vez disso decidir o que é mais importante para ser feito primeiro, refinando e desafiando o escopo, decidindo por implementar uma parte dos requisitos que seja o suficiente para finalizar um pedaço ou uma visão inicial.
Em seguida vem acompanhar o progresso. Existem diferentes formas para acompanhar o progresso como planilhas ou quadros kanban. Brown salienta que estes são utilizados para conhecer o progresso durante a iteração, mas eles não acompanham releases do software.
A arquitetura funciona? Tudo é inútil se a solução resultante não funciona como desejado. Brown considera que uma solução para funcionar tem que satisfazer os seguintes requisitos:
- satisfazer os pontos arquiteturais: os requisitos funcionais e não funcionais, as regras de ambiente e os princípios adotados
- prover uma base sólida para o código, que possa ser desenvolvida em cima
- prover uma plataforma para resolver os problemas iniciais de negócio que tenta resolver
Gerar um protótipo. Não importa quão grande a arquitetura é, não importa quão bonito o código aparenta ser, ninguém sabe se o sistema vai funcionar satisfatoriamente e se ele vai ser ampliado ou não. Um protótipo é necessário. O protótipo é a prova de conceito contendo algumas visões do sistema, verificando os requisitos apenas para simular o funcionamento, em por todo o sistema em pressão em um teste de carga. O código usado para o protótipo pode ser utilizado posteriormente ou pode ser jogado fora.
O teste de carga é feito por "simular múltiplos usuários com um perfil de uso, e preferencialmente com um ambiente mais próximo de produção possível". O protótipo e teste de carga devem ser feitos bem cedo afim de validar a arquitetura.
Utilizar um repositório de fontes é um passo importante quando se cria uma solução por prover: backup do código fonte, logs para as mudanças, uma forma de reverter problemas de versionamento e permitir o desenvolvimento em paralelo.
Teste automatizado é outra peça do jogo. O código recém adicionado está quebrando algo? Mudanças feitas por um novo caso de uso do projeto pode ter efeitos negativos no projeto. Para limitar os possíveis danos das mudanças, testes unitários e testes de integração são obrigatórios, caso contrário toda a funcionalidade do sistema precisa ser testada manualmente após cada mudança. Quanto testar? Brown considera que 100% é difícil alcançar, mas sugere 80% pegando a maior parte do código.
Build automatizado. Após o código testado, é necessário gerar e fazer deploy nas máquinas. Mas muitas vezes o build não funciona na outra máquina, e o script de build é necessário para que o sistema seja apropriadamente gerado em outras máquinas.
Outro passo muito importante de acordo com Brown é utilizar Integração Contínua. Um servidor de integração contínua irá automaticamente recuperar o código fonte do repositório, compilar, testar, empacotar e instalar o projeto, sinalizando qualquer erro que acontecer no processo. Isto ajuda para que o código seja gerado corretamente ou qualquer problema seja identificado cedo.
Automação de testar um build introduz Consistência e Repetibilidade. Automação é mais útil quando feita em parelalo com o desenvolvimento, trabalhando em vários ramos do código.
Externalize a informação de configuração. A configuração do sistema depende do ambiente e deve ser mantido fora do código.
A versão da aplicação deve estar contida em algum lugar: em meta-data, página de diagnóstico, no arquivo de log para estar certo da versão que se está utilizando quando necessário.
Um último passo, a Documentação Operacional. Se o time de desenvolvimento não está dando suporte, então é necessário a documentação operacional, contendo informação de como o sistema deverá ser utilizado, monitorado e gerenciado e como os problemas são diagnosticados.
Todos estes elementos que contribuem para criar um produto que tem chance de ser sucesso estão na imagem abaixo:
