3 erros que os desenvolvedores continuam a cometer

É impressionante o fato desses 3 erros ainda serem cometidos hoje em dia! Depois de tanto investimento em qualidade de software e em processos de desenvolvimento, existem vários erros que continuam a ser repetidos na maioria dos projetos, dentre esses, eu listei 3 que eu vejo com frequência ocorrerem juntos. 

Aproveite o Carnaval, e leia esse artigo, no intervalo do bloco ou da escola de samba, para quando voltar ao trabalho, evitar que aconteçam.

Sinceramente, tem horas que eu fico desesperado, ao notar que erros grosseiros, que causam grandes prejuízos, ainda continuam a serem cometidos pelos desenvolvedores! Outro dia, um amigo me chamou para conhecer o projeto que ele estava desenvolvendo, com uma equipe "ágil" de oito outros desenvolvedores. Vi o projeto e, em cerca de 15 minutos, encontrei os 3 cavaleiros do apocalipse presentes!

Eu deveria ter ficado calado, para não perder um amigo, mas resolvi dar alguns toques sutis. O problema é que, para cada "toque" que eu dava, ele ou alguém do Projeto defendia o erro! Então, calei minha boca...

Cara, existem vários erros grosseiros que você deve evitar em projetos de software. Eu procurei listar os 3 que mais ocorrem em conjunto, para que você os evite. É claro que existem erros até mais graves, porém, o que observei é que estes 3 ocorrem geralmente juntos.

1) Teste para inglês ver

Eu estou ficando velho, logo, fico me repetido o tempo todo. Tenho certeza que já falei aqui várias vezes sobre a importância do teste automatizado, e de suas características de abrangência e itempotência.

Este problema não é a falta de testes, mas a ausência de testes eficazes. Para passar "bem na foto" os desenvolvedores até criam casos de teste, mas não são abrangentes e, muitas vezes, são inócuos quando se trata de avaliar o software. Qualquer métrica de cobertura de código pode revelar esse problema. Porém, os imbecis dos gerentes, só verificam se existem testes e se o software passou por eles, e não a sua qualidade. E, para piorar, um teste pode ser abrangente e ser ineficaz.

Eis as "modalidades" desse erro:

• O código de teste é mantido fora do repositório de código-fonte do Projeto;
• Quem fez o teste, o manteve em sua máquina;
• Para tornar a integração mais rápidas, os testes antigos são removidos;
• Testes que só servem para fazer bonito, mas são ineficazes na avaliação dos resultados;

 Cara, aprenda de uma vez: TESTE É PRODUTO E O CLIENTE PAGOU POR ELE! O cliente tem todo direito de saber como você testou o sistema.

Como evitar?

Revise constantemente o código de teste!

O código de teste tem que ser avaliado assim como o código funcional. E deve ser em três níveis:

• Testes unitários: Testa se a unidade funciona como o esperado, exercitando o máximo de código possível e avaliando corretamente se os resultados e se as pré e pós condições estão satisfeitas; 
• Testes de integração: Testa as interfaces! Deve ser feito com base na definição de interfaces, e deve avaliar adequadamente se o método declarado fez o que deveria, se os tipos e valores limítrofes estão sendo respeitados, se a condição final foi a esperada etc;
• Testes funcionais: Devem avaliar o sistema "por fora", como se fosse o usuário, testando as condições limítrofes, fazendo besteiras, verificando os resultados etc.

É perfeitamente possível fazer um teste, que apresente excelente cobertura, mas que, na verdade, deixe de avaliar se o resultado foi o esperado.

2) Versionamento por insegurança

 A presença de código comentado (ou código morto) em um software, deveria ser passível de pena de morte. Há quase nenhuma razão para isto acontecer, e é uma grande fonte de problemas. É uma maneira "tosca" de fazer um controle de versão, mantendo o código antigo só para o caso do usuário mudar de ideia.  Muitos programadores comentam partes do código ou deixam o código antigo sem ser invocado (código morto), apenas para preservar a versão anterior.

É fruto da insegurança e pode confundir outros desenvolvedores, pois ninguém faz manutenção em comentários, e, se esse código realmente precisar ser utilizado, ele poderá estar incorreto ou desatualizado.

Se você não for um perfeito idiota (até porque perfeição não existe), então deve usar um sistema de versionamento de código-fonte, como o Git ou o Subversion, por exemplo. Então, dessa forma, mesmo o código que você deletou ainda estará lá, em uma versão mais antiga. Se for necessário reativá-lo, basta recuperar o histórico.

Como evitar? 

As ferramentas de análise estática moderna podem ajudar a encontrar código morto e código comentado. Porém, existe um caso mais difícil, que é o do "método morto", ou seja, um método público deixou de ser invocado e é mantido no código-fonte. Neste caso, somente uma bateria de testes pode ajudar.

Acostume-se a revisar o histórico dos "commits" feitos no repositório, para ver o que os programadores estão fazendo.

3) Programação por presunção

O programador presume que ele é o "fodão" e que é capaz de fazer qualquer coisa, então, ao invés de usar componentes prontos, ou soluções já consagradas, prefere fazer ele mesmo o código-fonte, gerando um altíssimo risco para o Projeto.

O caso clássico que eu uso é o "parse" de XML usando "substring". Esse "antipattern" consiste em criar código que analisa um arquivo XML manualmente, procurando "<" e identificando os "tags" através de "substrings". Certa vez, eu vi um método com mais de 1.000 linhas de código (ATENÇÃO: MAIS DE 1.000 LINHAS DE CÓDIGO EM UM ÚNICO MÉTODO DE UMA ÚNICA CLASSE), cujo objetivo era exatamente analisar um XML.

Mas as tolices geradas pela presunção realmente não possuem limites... Na situação que eu descrevi (o projeto do meu amigo), eles estavam fazendo análise de JSON com "substring"!!!!!! PelamordeDeus! O que é isso??????

Eu já vi de tudo! Programador abrindo socket e criando protocolo, programador criando PDF na mão, programador reescrevendo o bytecode dinamicamente, e outras inúmeras tolices. E em todos esses casos, há um programador presunçoso e um gerente idiota (desculpem o pleonasmo).

Como evitar?

Deve haver um arquiteto em todo o projeto, e esse cara deve identificar os desafios e apontar as soluções. Vai fazer análise de JSON? Então use os componentes JSON.org ou o Jackson, para os transformar em Objetos. Devem haver inspeções constantes nos projetos, antes que seja tarde demais.

Soluções artesanais e caseiras devem ser descartadas. Quanto menos código você produz, menor o risco que você tem em seu projeto.

Conclusão

A ocorrência destes 3 problemas, repetidamente, denota uma falha grave de gestão. Por muitos anos, os bons programadores continuavam a serem programadores, e os medíocres, viravam gerentes. É por essa razão que temos tantos gerentes incompetentes nas áreas de TI.

Essa praxe de desvalorizar a liderança técnica, relegando os bons desenvolvedores a segundo plano, acaba criando essas situações críticas nos Projetos.