Uma resposta direta
Outras respostas são bons "meta-pontos" sobre a adoção de melhores práticas, mas, para dar a você uma orientação diretamente relevante, aqui está uma ordem aproximada das melhores práticas que eu sugeriria à sua equipe (ou qualquer equipe) adotar (primeiro):
- Controle de origem
- Acompanhamento de problemas (gerenciamento de projetos e tarefas)
- Construções automatizadas 1
- Implementações automatizadas
1 Uma prática muito relacionada é automatizar, ou pelo menos documentar , a configuração do ambiente de desenvolvimento e desenvolvimento de cada aplicativo ou projeto de software que você está desenvolvendo ou mantendo. É muito menos útil porque você (com sorte) raramente ou raramente faz isso.
Tudo o resto
Você menciona várias outras boas práticas - "teste de unidade, registro, normalização de banco de dados, ... refatoração, ... documentação" - mas todas essas são práticas que podem e devem ser adotadas gradualmente e incrementalmente. Nenhum deles precisa ser adotado de uma só vez e você provavelmente os adotará melhor adotando-os com cuidado e atenção.
As quatro práticas listadas acima também tornarão a adoção e a experimentação de novas práticas o mais fácil possível. Por exemplo, o teste de unidade pode ser incorporado em suas construções automáticas e a documentação pode ser publicada como parte de suas implantações automatizadas.
Algumas das outras práticas que você menciona - "desenvolvimento ágil, ... guias de estilo de codificação, ... revisões de código, ... métodos de documentação padronizados" e estruturas (por exemplo, Spring) - são realmente opcionais ou de valor duvidoso. E isso é verdade sobre muitas práticas possíveis que você descobrirá ou encontrará.
O desenvolvimento ágil não é obviamente superior a qualquer outra metodologia utilizada. E muitas pessoas (inclusive eu) tiveram experiências horríveis com isso. Mas muitas pessoas realmente gostam (ou amam) também. Experimente!
Guias de estilo de codificação podem ser úteis, especialmente para grandes projetos, ou em grandes equipes, mas também é muito trabalhoso impor essas diretrizes, o que pode não ser o melhor uso do tempo de quem quer que esteja fazendo isso.
As revisões de código também podem ser muito úteis: você solicitou a seus colegas de trabalho que revisassem seu código? Tenha em mente que você não precisa de um processo formal para adotar boas práticas!
A documentação é ótima - você tem alguma? Se assim for, bom para você! Você está enfrentando muito trabalho extra que poderia ser evitado com a documentação (mais) "padronizada"? Se você é, então provavelmente é algo que vale a pena fazer. No entanto, diga se o seu software está sendo usado por um pequeno grupo de pessoas, você pode não precisar de qualquer qualquer documentação. (Ou você poderia incorporar diretamente a documentação em seu software. Essa é sempre a minha preferência.)
Estruturas são ... uma espada de dois gumes (muito afiada). Uma solução bem encapsulada e bem mantida para um recurso não essencial de seu software é ótima ... até que não seja. Eu não tenho certeza do que "controladores frontais escritos à mão" são exatamente, mas não há uma explicação óbvia de por que eles são inferiores ao código que aproveita o Spring. Você já pensou em encapsular a lógica comum em todos esses controladores em sua própria estrutura interna? Adotar o Spring, e reescrever todo o seu código existente, pode ser um imenso projeto de refatoração (ou, mais provavelmente, de reescrever) e essa pode não ser a melhor mudança que você poderia fazer no seu código . É claro que você não deve escrever todos do software que você usa - frameworks (e bibliotecas) são ótimos! Mas talvez não seja necessário usar o Spring (ou uma alternativa) para criar ótimos (ou bons) aplicativos da Web.