Renan de Lima

Quando se fala de qualidade em Tecnologia da Informação, logo se pensa em CMM, MPS ou algo do tipo. Esses padrões são, em geral, gerais. De outra maneira e sem trocadilhos baratos os guias/padrões para a qualidade de software tratam de cuidar do nível gerencial. Tratam a qualidade de código como resultado de uma boa gerência.

Isso é errado? Se observamos da ótica “código bom é o código que funciona” (…) isso é certo!

Sugiro observamos a qualidade de software de maneira micro, pelas atividades. Para isso precisamos antes definir o que é qualidade de atividade de programação.

Aponto abaixo os itens básicos e necessários para a boa execução de atividade de programação, originárias das minhas experiências como programador. Estou deixando de lado itens como padrão de código, arquitetura, modularização dos componentes de software e sagacidade do programador. Se você teve outras experiências diferentes e queira colaborar ou questionar, sinta-se a vontade. Os itens básicos e necessários para a boa execução de uma tarefa são:

• Documentação: Clareza na definição do que deve ser feito e atalhos para os recursos/informações necessários para a execução da tarefa.
• Prazo: Compatível com o parecer técnico e sano do programador.

Nessa visão qualidade de atividade de programação é “código que funciona e no prazo!”. Ou seja, se os itens necessários não forem cumpridos, não consigo executar uma atividade de programação com qualidade.

Mas como faço pra saber se executei uma tarefa com qualidade? Faço a análise com quatro perguntinhas básicas. Se atente às palavras “inicialmente”, “realmente” e “fácil”, não as ignore. As perguntas são:

• Eu realmente terminei a tarefa?
• O que eu fiz é exatamente o que eu entendi que deveria ser feito inicialmente?
• Os recursos/informações que precisei foram de fácil acesso?
• Realizei a tarefa no prazo inicialmente determinado?

Não existe resposta certa para as questões. Por exemplo, um “não” como resposta para a segunda pergunta deve nos instigar a entender o que ocasionou a falha no entendimento do objetivo da tarefa. E como Caetano já dizia a culpa para os “nãos” respondidos pode ser minha, ou não.

Não dê pipoca aos programadores!

Dê documentação e prazo!