Uma coisa que coloco com razoável frequência quando um cliente me pede revisão de arquitetura é que o código não tem expressividade. O que isso quer dizer? Quer dizer que você lê o código e não entende o que está acontecendo; não entende o propósito do código.

A Ubiquitous Language do DDD já ajuda bastante, pelo menos no que diz respeito a nomeação de classes e seus membros públicos. Mas muitas vezes os membros internos das classes, como métodos e variáveis privados, continuam tendo nomes sem expressividade. O código dentro dos métodos continua sem expressividade, ainda que a interface do objeto seja expressiva.

E mesmo utilizando com a Ubiquitous Language dá para bagunçar bastante. Não basta usar a linguagem do negócio no código se você acabar misturando ou adaptando os conceitos.

Então o cliente me chama para revisar a arquitetura e acaba ouvindo que o código dele não tem expressividade e que ele precisa nomear melhor seus objetos (claro que essa é só uma das observações, entre várias outras). E isso geralmente é um assunto que pega bastante, porque boa parte dos desenvolvedores tem o ego maior que o próprio conhecimento e acha que a sua maneira de fazer as coisas é melhor, principalmente na hora de nomear classes, métodos, propriedades e eventos.

Isso faz diferença? Faz. Faz muita diferença. Código que não dá para entender entra de cara na categoria de código legado. Não importa se você escreveu hoje de manhã, se não dá para entender é código legado. Código que não é legado deve ser compreensível. Como vou conseguir compor a arquitetura de uma solução se os objetos têm nomes como “BSCliente”, ou “FrmCadastro”, ou “ItemSelecao”? Impossível. Quer dizer, não é impossível, porque a primeira coisa que eu vou recomendar é justamente ajustar estes nomes, aí sim vamos conseguir tentar entender o que está acontecendo.

O interessante é que o desenvolvedor, conforme começa a revisar o nome dos objetos, começa a perceber que há um monte de conceitos errados, que o princípio de responsabilidade única está quebrado em tudo quanto é lugar, que há repetição de responsabilidade, entre outras coisas. Aí então começa a entender o que eu estava propondo.

Li um tempo atrás um post do MVP Greg Young chamado “DDD: Specifications, Language, and Locality”. Neste post o Greg, que posta frequentemente no grupo de discussão sobre DDD (infelizmente todo em inglês, mas você pode obter experiência semelhante indo ao grupo online do .Net Architects, todo em português), coloca um exemplo interessante do uso de especificações versus propriedades. Muita gente me pergunta quando e onde usar especificações, e o Greg coloca com bastante propriedade onde, quando e porquê. Além de um bom exemplo com especificações, é também um ótimo exemplo de utilização da Ubiquitous Language para aumentar a expressividade do código, e ela entre fundo nas explicações do porquê.

Em resumo: leia o seu código quando você terminar de codificar. Se você perceber que há nomes que não explicitam o que você queria dizer quando escreveu o código pense em renomeá-los.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.