“Mas pra quê serve esse checklist, mesmo?”

10:01 am Desenvolvimento

Faz um certo tempo que li um artigo muito interessante do Jason Cohen no CM Crossroads com o título “Checklists – You build me up just to knock me down”. Resumidamente, o autor trata da construção de checklists de revisão de código mais eficientes e para isso ele cita algumas “regras do dedão”, como:

  • 10 itens no máximo, porque mais do que isso atrapalha e torna o preenchimento cansativo para o revisor. Para ratificar esse valor, ele cita George Miller [1], autor do famoso estudo sobre a capacidade cognitiva humana de processamento de informação que propõe como limite sete mais ou menos dois.
  • Nada de itens genéricos ou óbvios como “o código faz o que é esperado” ou “o código está legível”, pois a revisão é feita justamente para encontrar esse tipo de problema.
  • Nenhum item que possa ser detectado de forma automática via ferramentas como PMD, FindBugs, Checkstyle, dentre outras.
  • Verificar coisas fáceis de esquecer, como fechamento de conexões de banco.
  • Construir o checklist de forma empírica, com os erros mais freqüentes da equipe para uma determinada tecnologia.
  • Sempre atualizar o checklist e remover os itens que não são mais relevantes.

Apesar de tratar de revisão de código, essas dicas podem ser empregadas em outros checklists, como de revisão de modelo de arquitetura, de especificação de caso de uso, plano de projeto, etc. Porém, uma coisa que me chamou a atenção no artigo foi algo não abordado por ele: a função do checklist. Qual é a utilidade daqueles papéis ou planilhas que, em muitas vezes, são preenchidos de forma “automática” e sem muita atenção?

A primeira e mais óbvia é de guia. Como não se pode contar com o “bom-senso” do revisor na inspeção do artefato, o checklist serve como um roteiro a ser seguido durante a verificação, uma base de critérios a serem inspecionados que asseguram a qualidade do artefato desenvolvido.

A segunda função, menos evidente, é a de contrato. Ao preencher o checklist, o revisor atesta que os pontos citados foram verificados e que o artefato está de acordo com o padrão estabelecido. Essa função pode não ser muito clara em grande parte das inspeções, mas ela fica evidente em “pré-verificações”, ou seja, naquelas em que o revisor é o próprio autor do artefato. Recordo-me de um checklist de término de implementação, utilizado em um dos projetos no qual trabalhei, e que funcionava da seguinte forma:

  • ao final da implementação de um caso de uso, o desenvolvedor preenchia um checklist contendo algumas verificações a serem feitas no caso de uso, como se o fluxo principal era seguido corretamente, se não havia mensagens sem tradução na interface, se os botões funcionavam corretamente, dentre outras;
  • se o desenvolvedor detectasse algum problema, ele retornava à codificação para corrigir o problema encontrado.
  • se nenhum dos problema listados fosse encontrado, o desenvolvedor entregava o checklist preenchido para o testador, atestando que o código estava pronto para ser testado;
  • o testador verificava novamente os itens do checklist e se aparece alguma não-conformidade, um bug era criado na ferramenta de controle de issues e o desenvolvedor era “amigavelmente advertido” pelo gerente do projeto. :-D

Problemas encontrados pelo testador em um dos itens do checklist eram como uma quebra de contrato entre o desenvolvedor e o testador, passível de retaliação. Lembro-me que antes desse processo ser implementado, os testadores reclamavam do grande volume de erros “bobos” encontrados durante os testes; depois do checklist, o número desses casos caiu sensivelmente (ah, as maravilhas do behaviorismo… :-D)

A terceira, mais sutil ainda, é a de evidência. Durante o processo de certificação de CMMI nível 3 da Vetta Technologies, os checklists de inspeção de código e de verificação de artefatos serviram não só como evidência de que esses procedimentos eram aplicados nos projetos mas também como comprovação que eram feitos de maneira uniforme, definida e documentada. Ou seja, algo que fazíamos de uma forma praticamente natural (e que muitos encaravam como apenas uma mera formalidade) foi de grande utilidade nesse processo.

Sendo assim, da próxima vez que for preencher um checklist, pense no que está fazendo: dependendo da função, a “mera formalidade” pode acabar em um belo “puxão de orelha”. :-D

[1] George Miller também é conhecido por ser um dos responsáveis pela criação do Wordnet, banco de dados lexical e semântico da língua inglesa bastante usado em projetos de processamento natural de linguagem e correlatos.

Paulo Ferreira de Moura Junior, bacharel em Ciência da Computação pela UFMG, é arquiteto e líder técnico da Vetta Technologies.