Em um artigo na InfoWorld, o consultor Andrew Oliver relaciona dez práticas de desenvolvedores altamente ineficazes. Segundo o autor, um desenvolvedor pode virar seu próprio inimigo ao buscar um código perfeito, ou usar práticas imprudentes ou equivocadas. O texto serve como uma reflexão, ou mesmo alerta, para os desenvolvedores que adotam, ou são obrigados a adotar, alguma das práticas examinadas.
Testes e Builds
Uma das práticas condenáveis, segundo Oliver, é passar dias sem escrever um teste unitário ou executar um build. Com relação aos testes, o autor diz que os programadores ficam mais preocupados em discutir se determinado teste é unitário ou funcional quando isso, na verdade, pouco importa. O importante é ter uma cobertura de testes que seja capaz de notificar os responsáveis, caso algo de errado aconteça.
Já com relação à não execução de builds, não haveria desculpas para isso, em tempos de ferramentas de automatização de builds fáceis de se configurar, como o Jenkins. Essas ferramentas, lembra Oliver, são capazes de notificar rapidamente quando algum imprevisto de compilação ou execução de testes automatizados acontece:
Executar seus builds repetidamente é como manter os batimentos cardíacos do seu projeto.
Versionamento
O autor dispara críticas também à utilização de controles de versão que comprometem a produtividade dos desenvolvedores, seja pela falta de velocidade da ferramenta, seja por trabalhar com lock pessimista:
Acho incrível ainda existir quem acredite que é melhor se ter metade do time esperando um arquivo ser liberado, do que ter duas pessoas trabalhando no mesmo arquivo (em partes diferentes que serão mescladas automaticamente).
Outra prática condenada é a disponibilização de novas versões em produção, sem a criação de um branch. A utilização desse recurso permite à equipe prosseguir, em um ramo de versionamento paralelo, com o desenvolvimento de melhorias e novas funcionalidades, sem isso interferir na correção de eventuais problemas encontrados em produção. Um programador que opta por não utilizar branches corre sério risco de colocar em produção códigos incompletos juntamente com a correção de erros emergenciais, causando problemas tanto aos usuários como para o ambiente de produção.
Desempenho e escalabilidade
Quanto ao assunto performance e escalabilidade, Andrew Oliver diz que um problema grave é desenvolver uma funcionalidade sem nenhuma informação, ainda que vaga, a respeito das métricas dos requisitos não funcionais relacionados. Tais informações são importantes tanto para a implementação correta, como para o desenvolvimento de testes de carga que possam verificar se as estimativas de resposta estão sendo atendidas.
O consultor também defende que não se deve realizar testes de carga somente no final, e sim durante todo o projeto, para que, constantemente, sejam validadas as implementações. Problemas relacionados à implementação de algoritmos e regras de negócio, ou a estratégias de concorrência, por exemplo, se descobertos tardiamente, podem tornar os requisitos inatingíveis. Isso acontece, seja pelo tempo necessário para reestruturação da solução, seja pela necessidade de alterar uma decisão arquitetural que afetará diversas partes do sistema.
Outra decisão equivocada, na análise de Oliver, é decidir por reimplementar soluções já existentes e consolidadas no mercado, como pool de conexões, cache, gerenciamento de transações. Decisões desse tipo devem ser tomadas apenas se você trabalhar em uma empresa que atua, efetivamente, com essas implementações. Em 99% dos casos não vale a pena abrir a mão de soluções consolidadas no mercado pelo "preciosismo de escrever um software melhor que o existente".
Oliver condena, ainda, a utilização de interações nativas com bancos de dados, ao invés de se usufruir de soluções de mapeamento objeto-relacional já existentes. Para ele, não vale a pena perder todos os benefícios trazidos por uma solução desse tipo.
Envolvimento dos usuários
Um ponto adicional condenado pelo autor, e cada vez mais condenado pela comunidade de desenvolvimento de software, é a demora no envolvimento dos usuários durante o desenvolvimento. Os usuários são peças fundamentais e indispensáveis durante a implementação de um sistema; não só por serem os consumidores do que está sendo produzido, como também por serem as únicas pessoas com reais condições de fornecer feedback, no sentido de dizer que o que está sendo entregue foi produzido da forma esperada.
O artigo inclui várias outras análises e gerou bastante discussão nos comentários. E você, quais das práticas "ineficientes" tiraria da sua lista e quais novas práticas adicionaria?