Tecnologia. Inteligente.

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.

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”.

[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.

Naquele estranho (e meio nojento - tudo bem, muito nojento) filme de 1986 do Cronenberg, “A Mosca”, em algum momento a repórter interpretada pela Geena Davis pergunta ao cientista vivido pelo Jeff Goldblum como ele conseguiu construir um teleportador do nada no galpão dele. O cientista responde que na verdade ele não fez aquilo sozinho e nem do nada, ele contratava equipes de cientistas ao longo do globo pedindo coisas esquisitas do tipo “quero um analisador molecular obedecendo tais e tais especificações”, e aí uns meses depois lá chegava o analisador molecular. As equipes independentes de cientistas que resolviam esses sub-problemas e criavam esses componentes só enxergavam o que precisavam enxergar, não tinham noção de onde a solução que eles desenvolveram seria aplicada, e principalmente não tinham a menor idéia do projeto do teleportador que o personagem principal estava desenvolvendo.

No mundo real, longe das referências nerd envolvendo obras de ficção científica, devo dizer que nós aqui do Vetta Labs às vezes nos sentimos um pouco como os cientistas do filme que construíram o analisador molecular sabe-se lá para ser usado em que. Como diz o ditado, “o segredo é a alma do negócio”, e isso é particularmente aplicável quando o negócio envolve a análise de informações de outras empresas que querem ao mesmo tempo terceirizar serviços de mineração de dados e preservar o sigilo de seus contratos e seus clientes.

Pois bem, uns meses atrás, em mais um daqueles exemplos das maravilhas do outsourcing de pesquisa, fomos contratatos pela Novamente para analisar os dados de um terceiro cliente-cujo-nome-não-será-revelado, que como dá para suspeitar pela omissão do nome era justamente desses que preferem manter seus dados e planos envoltos em mistério. Recebemos uma base de dados composta por dezenas de milhares de tuplas, cada uma formada por um punhado de valores correspondendo a um pequeno conjunto de variáveis. O problema que nos foi colocado foi tentar prever uma das variáveis em especial com base nos valores de todas as outras, com uma taxa de acerto superior a um certo limite mínimo aceitável. A variável a ser predita era, para todos os fins práticos, lógica, do tipo “sim” ou “não”. As demais variáveis eram bem variadas, algumas claramente numéricas, outras também lógicas, e finalmente umas que talvez fossem numéricas ou talvez fossem simbólicas. O caso é que não tínhamos nem muita certeza do tipo de algumas das variáveis porque não nos foi dada qualquer informação sobre as mesmas. Os nomes de algumas variáveis até davam pistas do que elas deviam ser (mas não exatamente em que unidades elas estavam sendo medidas), porém outras variáveis tinham nomes herméticos que não ajudavam muito do ponto de vista da, digamos, semântica dos dados.

Assim, inventando uma base de dados parecida para fins de exemplificação, vamos supor que temos um conjunto aparentemente desprovido de sentido de quatro variáveis chamadas TUTU, PEDRA, CAVALO e CHUVA, e com base nelas temos de prever se o valor de uma quinta variável RESPOSTA é “sim” ou “não”. Existem dezenas de milhares de combinações-exemplo de valores de TUTU, PEDRA, CAVALO e CHUVA com valores conhecidos de RESPOSTA, e com base nelas devemos achar regras engraçadas como, digamos, “Se TUTU vale mais que 0.65, PEDRA tem valor ‘mole’ ou ‘redonda’, CAVALO pode ter qualquer valor e CHUVA vale ‘forte’, então RESPOSTA é ’sim’, caso contrário ‘não’”, regras essas capazes de prever RESPOSTA corretamente com uma acurácia maior que um mínimo estipulado pelo cliente.

Numa situação dessas, o bom minerador de dados deve se ater àquela máxima que acredita-se o filósofo-patrono das ciências exatas, o Pitágoras, soltou uns 25 séculos atrás: “Tudo são números”. É verdade que, como já exemplificamos várias vezes aqui no blog, quando mais informação você tem sobre uma base de dados, melhor, e às vezes é inclusive interessante usar outras bases de dados direta ou indiretamente relacionadas para “amplificar” a base objeto do seu estudo. Porém, nas situações em que não podemos (ou não devemos saber mais a respeito dos dados, o puro uso da lógica e da matemática podem ainda assim ser surpreendentemente efetivos.

Foi assim no caso dessa base de dados “misteriosa”. Devo dizer que criar uma abordagem capaz de passar do limite de acurácia mínimo pedido pelo cliente foi bem… desafiador, talvez inclusive devido ao desconhecimento da semântica dos dados. Mas, no final, chegamos a uma método bem robusto capaz de resolver até nossas dúvidas sobre o tipo exato de algumas variáveis. Nessa metodologia (da qual falarei apenas por alto para não “falar demais” :), desenvolvemos uma maneira de medir a “capacidade de predição” de uma variável quando assumia um dado valor (não importando se esse valor é um número, uma string, lógico, etc), e também para qual resposta (”sim” ou “não”) tendia esse dado valor de dada variável. No final, ao contrário do exemplo acima, nossas regras verificavam não os valores diretos das variáveis, mas sim a capacidade de predição dos valores que elas estavam assumindo na tupla em questão, e com base nisso decidiam se a tupla apontava para “sim” ou um “não”.

Conseguimos com essa abordagem ultrapassar (por pouco) a acurácia mínima pedida pelo cliente, inclusive em um segundo conjunto de tuplas completamente desconhecidas, seguindo o mesmo formato de dados, que o cliente nos forneceu para uma validação adicional. É possível que agora formalizemos um serviço de análise e desenvolvimento de mais longo prazo - e quem sabe até com um véu de mistério menos espesso. De qualquer forma, a lição que ficou foi: os números são seus amigos, não se desespere se eles são a única coisa ajudando você em seu trabalho de análise de dados.