Esta é a segunda publicação de uma série onde pretendo comentar sobre livros relacionados à programação de computadores, desenvolvimento de sistemas, engenharia de software e temas afins. Hoje, vou falar sobre o capítulo 2 de um dos livros mais famosos: Código Limpo, de Robert Martin, o Uncle Bob.
Este capítulo discute a importância de dar nomes significativos às entidades em um software. Embora pareça óbvio, a prática revela que não é tão simples. Um amigo meu, Leandro, costuma dizer que criar software é como um artesanato. Itens artesanais refletem muito da pessoa que os cria. Cada linha de código carrega a bagagem de toda a experiência do programador até aquele momento. O que pode parecer simples para alguém experiente em um determinado domínio, pode ser uma dor de cabeça para novatos. Isso cria armadilhas, pois, durante o desenvolvimento, pessoas com profundo conhecimento sobre um tema podem codificar informações de forma não tão clara.
Então, por que os nomes das coisas em um software são tão importantes a ponto de merecerem um capítulo inteiro em um livro? Minha resposta pessoal e rápida é que, embora os benefícios de bons nomes sejam óbvios, muitas vezes as pessoas não os utilizam da melhor forma possível. Todos os programadores têm algum nível de comportamento viciado. Por isso, é essencial conhecer boas práticas e, ainda mais, compartilhá-las em equipes de software.
Na minha jornada como engenheiro de software, já precisei lidar algumas vezes com sistemas legados onde os nomes eram apenas códigos, especialmente em tabelas de banco de dados. O livro Código Limpo é claro ao afirmar que esse tipo de comportamento adiciona uma complexidade desnecessária. Imagine ter que lembrar que “tb3265n” é a tabela com informações de pessoas, entre centenas de outras tabelas. Isso adiciona uma carga extra de esforço mental. No entanto, entendo que este é um caso particular, pois o responsável pelo projeto inicial optou, intencionalmente, por fazer dessa forma.
De modo geral, os nomes das coisas em um software devem revelar seu propósito. Declarar uma variável como int elapsedTime é bom, mas int elapsedTimeInDays é ainda melhor, pois elimina possíveis interpretações equivocadas. Em ambos os casos, um novato encarregado da manutenção entenderia o propósito da variável, mas seria menos problemático no segundo caso. Evitar mapeamento mental é crucial, pois quem escreveu o código tem a informação fresca em mente. Outras pessoas, no futuro, podem ter dificuldade em relacionar um nome ao seu propósito.
Quanto ao mapeamento mental, o caso dos contadores i e j é uma exceção. Programadores aprendem desde os primeiros momentos nos estudos de lógica de programação que essas variáveis são usadas para contar ou controlar o fluxo em um laço for, por exemplo. Tudo bem usar i, j, k, mas não l, pois pode ser confundido com o número “1” ou a letra “I” em algumas fontes.
Os nomes das coisas em um software precisam ser confiáveis. Uma rotina chamada PersonRepository.findPerson(personFilter) sugere que uma pessoa será procurada em alguma fonte de dados. Seria ruim se, além de procurar a pessoa, essa rotina também salvasse algumas informações no banco de dados, pois essa função não está descrita em seu nome.
O capítulo 2 do livro Código Limpo está repleto de dicas, desde a necessidade de evitar informações erradas até o uso de nomes pronunciáveis e facilmente localizáveis em uma IDE por meio da função de busca textual. Ele também aborda a importância de usar nomes próximos ao domínio do software; por exemplo, em um sistema hospitalar, faz mais sentido chamar um objeto de “paciente” ou de “cliente”?
Por fim, Robert Martin conclui o capítulo afirmando que dar bons nomes às coisas está mais relacionado ao aprendizado do que à técnica ou à gestão corporativa. Além disso, renomear elementos pode fazer parte da rotina de desenvolvimento. A maioria das ferramentas, como IDEs, oferece recursos que facilitam essa tarefa com apenas dois cliques do mouse.
Recomendo fortemente a leitura completa do livro. Abraços!
