O novato e a qualidade de código

Todos já fomos, um dia, um novato de desenvolvimento de software. Isto não é vergonha alguma. É natural, e até esperado, que os novatos cometam mais erros com frequência e encontrem mais dificuldades nas atividades diárias de desenvolvimento.

Muitos deles chegam nas empresas vindo de bons colégios técnicos, já sabendo programar em alguma linguagem, normalmente Java. O porém é que conhecer a linguagem de programação não é garantia que aquela pessoa saiba escrever um bom código. Não estou falando que ela vai precisar de anos para aprender isto também. Existe uma série de ações que poderiam ser feitas para/por esta pessoa recém-chegada na empresa, e que não é feito, que alteraria significativamente a qualidade do código escrito por ela.

Mas o que poderia ser feito? Estava eu outro dia na Amazon, olhando alguns comentários sobre um dos melhores livros de desenvolvimento de software já escritos, o Code Complete, livro este que citarei várias vezes neste blog. Foi quando me deparei com este comentário, e este trecho me chamou a atenção:

The most common criticism one hears about this book is that any decent software developer should already know the material covered in it. Ironically enough, this is true

Em uma tradução livre: "A crítica mais comum ouvida sobre este livro é que qualquer desenvolvedor decente de software deveria já saber do conteúdo coberto pelo livro. Ironicamente, isto é verdade".

Sim, é verdade. Há muito conhecimento que poderia ser facilmente passado para um desenvolvedor em início de carreira sem exigir necessidade de experiência para adquirir este conhecimento. Mas o que ocorre com frequência é que ele começa no projeto sem preparo e, dependendo da dinâmica do desenvolvimento, começa a cometer com frequência diversos erros. As consequências alguns já imaginam:

• Código de difícil leitura;
• Nomes ruins para variáveis, métodos, classes, etc;
• Uso de variáveis globais;
• "Reinvenção da roda";
• Necessidade de refatoração posterior;
• Estresse por parte de alguns membros mais experientes da equipe;
• Bugs que poderiam ser facilmente evitados;

Boa parte destes problemas seriam evitados se ele tivesse uma boa comunicação com o restante da equipe. Mas estamos falando de alguém com sua primeira experiência de empresa, recém-chegado, querendo mostrar serviço, precisando lidar com outros estagiários "prodígio", com medo de fazer uma pergunta considerada "boba" por ele, recebendo pressão de entrega e até recebendo mais responsabilidade do que deveria... Devemos dar o braço a torcer e reconhecer que vários destes problemas acima citados são de responsabilidade da equipe também.

No próximo post, vou falar da equipe e o seu envolvimento na qualidade de código. Até mais!