Towards a Taxonomy of Software Log Smells

Este estudo propõe uma taxonomia de nove "maus odores" (smells) de logs, derivada de uma revisão sistemática da literatura e mapeada para ferramentas existentes, com o objetivo de auxiliar desenvolvedores a escreverem código de log de maior qualidade e identificar lacunas na pesquisa atual.

O essencial

Imagine que o software é como uma casa em constante construção. Os desenvolvedores são os pedreiros e engenheiros que constroem os cômodos, instalam a eletricidade e pintam as paredes.

Agora, imagine que, enquanto trabalham, eles deixam um diário de obra (os logs). Esse diário é crucial. Se a casa pegar fogo ou uma torneira começar a vazar, os bombeiros e encanadores olham esse diário para entender o que aconteceu, quando e por quê.

O problema é que, muitas vezes, esse diário é escrito de forma bagunçada, confusa ou até mentirosa. É aí que entra o conceito de "Cheiro de Log" (Log Smells).

O que é um "Cheiro de Log"?

Pense em um "cheiro" não como algo que você sente com o nariz, mas como um sinal de alerta. Assim como um cheiro de queimado na cozinha pode indicar um incêndio que ainda não se espalhou, um "Cheiro de Log" é um sinal de que algo está errado na forma como o software está sendo registrado, mesmo que o programa ainda esteja funcionando.

Se você ignorar esses cheiros, eles podem virar problemas graves: o sistema pode ficar lento, dados sensíveis podem vazar ou, quando algo quebrar, ninguém conseguirá consertar porque o diário de obra não faz sentido.

A "Caixa de Ferramentas" dos Problemas (A Taxonomia)

Os autores deste estudo foram como detetives que vasculharam a literatura científica para criar um catálogo de 9 tipos de "mau cheiro" que os desenvolvedores podem encontrar. Eles dividiram esses problemas em duas categorias principais:

1. O Problema está no Código (O Pedreiro): O erro está na forma como o diário foi escrito.
2. O Problema está no Diário (O Papel): O erro está no que foi realmente registrado.

Aqui estão os 9 "maus cheiros" explicados de forma simples:

1. Tempestade de Formatos (Format Turmoil)

• A Analogia: Imagine que um pedreiro escreve a data como "05/08", outro como "Agosto 5", e um terceiro apenas "5".
• O Problema: Os registros não seguem um padrão. É impossível usar um computador para ler tudo rapidamente porque cada um fala uma língua diferente.

2. Identidade Escondida (Undercover Identifier)

• A Analogia: O diário diz "Alguém quebrou a janela", mas não diz quem foi. Foi o João? A Maria? O gato?
• O Problema: Falta saber qual parte do sistema (ou qual "pedreiro") gerou o registro. Sem isso, você não sabe onde procurar o erro.

3. O Nível de Alerta Confuso (Mercurial Logging Level)

• A Analogia: Você usa um grito de "INCÊNDIO!" para avisar que o café acabou, e um sussurro para avisar que o prédio está desabando.
• O Problema: Os avisos de gravidade estão errados. Um erro pequeno é marcado como crítico, ou um desastre é tratado como algo trivial. Isso confunde quem tenta priorizar o que consertar.

4. A Variável Enganosa (Deceptive Variable)

• A Analogia: O diário diz "O valor é X", mas esquece de dizer que X é o preço do pão ou a temperatura do forno. Ou pior, escreve "Erro: [Objeto]" em vez de "Erro: Falha na conexão".
• O Problema: As informações registradas são vagas, erradas ou ilegíveis para humanos.

5. Loucura nas Mensagens (Message Madness)

• A Analogia: Um dia você escreve "Conexão estabelecida", no outro "Conectando..." e no outro "Falha ao conectar", tudo com gramática ruim e sem sentido.
• O Problema: As mensagens são inconsistentes, cheias de erros de português ou repetitivas, tornando a leitura um pesadelo.

6. O Log Perdido no Vento (Logging Lost in the Wind)

• A Analogia: O pedreiro esqueceu de anotar que a parede caiu. O diário simplesmente pula de "Construindo parede" para "Parede caída", sem registrar o momento da queda.
• O Problema: Informações cruciais não foram gravadas. Quando o problema acontece, o diário está em branco.

7. O Lixo no Log (Landfill Logs)

• A Analogia: O pedreiro anota tudo: "Respirei", "Pisquei", "O sol estava brilhando". O diário tem 1 milhão de páginas, mas a informação importante está escondida no meio de tanto lixo.
• O Problema: Excesso de dados inúteis. Isso deixa o sistema lento e torna impossível encontrar o que realmente importa.

8. Os Guardas Dormindo (Sleeping Guards)

• A Analogia: O pedreiro gasta energia escrevendo um relatório detalhado, mesmo que ninguém precise ler aquele relatório naquele momento.
• O Problema: O código gasta recursos (memória, bateria, tempo) para gerar logs que nem serão usados, ou gasta recursos para gerar logs que deveriam ser bloqueados.

9. O Esqueleto no Armário (Skeleton in the Closet)

• A Analogia: O próprio diário está escrito de forma tão confusa, com frases longas e repetidas, que é difícil para qualquer um entender como ele foi feito.
• O Problema: O código que gera o log é sujo, difícil de manter e cheio de erros de programação.

As Consequências: O Que Acontece se Ignorarmos?

Se você deixar esses cheiros ficarem, a casa pode:

• Vazar Segredos: O diário pode conter senhas ou dados de clientes expostos.
• Confundir o Tempo: O diário pode dizer que o evento A aconteceu antes do B, quando na verdade foi o contrário.
• Deixar a Casa Lenta: O excesso de anotações consome a energia da bateria do celular ou o processador do servidor.
• Causar Acidentes: O código de anotação pode interferir no funcionamento do software, causando travamentos.

Ferramentas para Limpar o Cheiro

Os autores também procuraram por "aspiradores de pó" (ferramentas automáticas) que consertam esses problemas.

• O que acharam: Existem 16 ferramentas que ajudam a corrigir alguns desses cheiros, especialmente os relacionados a níveis de alerta e mensagens.
• O que falta: Ainda não há ferramentas automáticas boas para consertar a "Tempestade de Formatos", os "Guardas Dormindo" ou o "Esqueleto no Armário". Isso significa que os desenvolvedores ainda precisam fazer muito trabalho manual nessas áreas.

Conclusão

O estudo nos ensina que escrever bons logs não é apenas "anotar coisas". É uma habilidade que requer cuidado. Se os desenvolvedores aprenderem a identificar esses "cheiros" cedo, eles podem evitar grandes desastres no futuro. É como checar a fumaça antes que a casa pegue fogo: um pequeno esforço agora evita um grande problema depois.

Resumo técnico

Aqui está um resumo técnico detalhado do artigo "Towards a Taxonomy of Software Log Smells", apresentado em português:

1. Problema e Contexto

O registro de logs (logging) é uma parte crítica do desenvolvimento de software moderno, essencial para tarefas como depuração, monitoramento e garantia de qualidade. No entanto, a produção de logs de alta qualidade é complexa e propensa a erros. Embora o conceito de "cheiros" (smells) — indicadores de problemas de design mais profundos — seja bem estabelecido em outras áreas da engenharia de software (como código e requisitos), ele não foi adequadamente definido ou taxonomizado no contexto de logs.

A literatura existente foca principalmente em onde, quando e o que registrar, mas carece de uma definição abrangente de "cheiros de log" que cubra tanto o código de registro quanto os arquivos de log resultantes. A falta dessa definição impede que desenvolvedores identifiquem precocemente más práticas que podem levar a consequências graves, como vazamento de informações, inconsistências temporais e degradação de desempenho.

2. Metodologia

Os autores conduziram uma pesquisa de literatura (survey) para identificar problemas de registro, cheiros e ferramentas de reparo. O processo seguiu as etapas abaixo:

• Fontes de Dados: Busca em Google Scholar, IEEE Xplore, Scopus e ACM Digital Library.
• Seleção: Foram analisados 475 resultados iniciais, dos quais 51 artigos foram selecionados após aplicar critérios de inclusão (papel revisado por pares, em inglês, relacionado a logs de software) e exclusão.
• Análise de Dados:
  • Codificação Aberta (Open Coding): Extração de termos e descrições de problemas dos artigos para formar uma lista inicial de questões de registro.
  • Classificação de Cartas (Card Sorting): Realizada em duas fases (aberta e fechada) com todos os autores. Na fase aberta, os problemas foram agrupados sem categorias pré-definidas. Na fase fechada, foram categorizados em três grupos principais: Causas, Cheiros de Log e Consequências.
• Mapeamento de Ferramentas: As ferramentas identificadas na literatura foram mapeadas para os cheiros e suas facetas específicas para determinar quais problemas podem ser automatizados.

3. Contribuições Principais

O artigo apresenta três contribuições fundamentais:

1. Definição de Cheiro de Log: Uma definição formal de "cheiro de log" como uma escolha de design pobre ou um problema que impacta a qualidade, podendo resultar em problemas mais sérios, afetando o código de log, o arquivo de log ou ambos.
2. Taxonomia de Cheiros de Log: Uma estrutura hierárquica contendo 9 tipos de cheiros, divididos em facetas específicas, além da identificação de 5 causas e 4 consequências diretas.
3. Mapeamento Ferramenta-Cheiro: Uma análise de 16 ferramentas existentes que tentam reparar ou remover esses cheiros, destacando lacunas onde a automação ainda é inexistente.

4. Resultados: A Taxonomia

A taxonomia classifica os cheiros com base no artefato afetado (Código de Log ou Artefato de Log/Arquivo).

A. Os 9 Cheiros de Log (Log Smells)

1. Format Turmoil (LS1): Problemas no formato dos logs (inconsistência, incompletude, múltiplos formatos no mesmo projeto).
2. Undercover Identifier (LS2): Identificadores ausentes ou incorretos que impedem a vinculação do log ao componente ou thread correto.
3. Mercurial Logging Level (LS3): Níveis de log ausentes, incorretos (ex: tratar um aviso como erro) ou inconsistentes para o mesmo tipo de evento.
4. Deceptive Variable (LS4): Variáveis ausentes, erradas, com saída malformada ou granularidade variável (ex: logar o objeto inteiro em vez do valor específico).
5. Message Madness (LS5): Problemas nas mensagens estáticas (ausentes, imprecisas, duplicadas, erros gramaticais, linguagem ambígua).
6. Logging Lost in the Wind (LS6): Ausência de entradas de log relevantes ou configuração de verbosidade muito baixa em tempo de execução.
7. Landfill Logs (LS7): Excesso de logs (redundantes, inúteis ou excessivamente detalhados) que obscurecem informações importantes e consomem recursos.
8. Sleeping Guards (LS8): Guardas de log (condições que controlam a execução do log) ausentes ou incorretas, causando execução de código desnecessário ou falha na geração de logs quando necessário.
9. Skeleton in the Closet (LS9): Problemas de qualidade no próprio código de log (código duplicado, longo, difícil de entender), afetando a manutenibilidade.

B. Causas e Consequências

• Causas (5): Falta de diretrizes gerais, conhecimento/experiência do desenvolvedor, uso de bibliotecas de log, componentes desenvolvidos separadamente e manutenção insuficiente do código de log.
• Consequências (4): Vazamento de informações (Information Leak), inconsistência temporal (Temporal Inconsistency), impacto no desempenho do sistema e efeitos colaterais acidentais do código de log.

C. Ferramentas de Reparo

Dos 9 cheiros identificados, 6 possuem ferramentas de reparo na literatura, mas o mapeamento revela lacunas significativas:

• LS3 (Nível de Log) é o mais coberto (7 ferramentas).
• LS1 (Formato), LS8 (Guardas) e LS9 (Código) não possuem ferramentas dedicadas de reparo automatizado.
• Muitas ferramentas focam apenas em facetas específicas (ex: apenas em exceções ou apenas em níveis), e não no cheiro como um todo.

5. Significado e Conclusão

O estudo demonstra que os problemas de log permeiam todo o ciclo de vida do software, desde o design até a execução. A taxonomia proposta oferece um vocabulário comum para desenvolvedores e pesquisadores discutirem e mitigarem esses problemas.

Pontos-chave de impacto:

• Conscientização: Ajuda desenvolvedores a entender que más práticas de log não são apenas "ruído", mas indicadores de dívida técnica que podem levar a falhas críticas de segurança e desempenho.
• Direcionamento de Pesquisa: A análise de ferramentas revela que, embora existam soluções para níveis de log e mensagens, há uma lacuna crítica na automação de correções para formatos, guardas de execução e qualidade do código de log.
• Prática Industrial: A taxonomia pode ser usada para criar diretrizes de codificação e ferramentas de análise estática mais eficazes, ajudando a evitar os "cheiros" antes que se tornem consequências graves.

Os autores planejam validar a taxonomia através de estudos empíricos em repositórios de software (MSR) e desenvolver novas ferramentas para os cheiros que atualmente carecem de soluções automatizadas.