“Qualquer idiota pode escrever código que um computador possa entender. Bons programadores escrevem código que os seres humanos possam entender.” – Martin Fowler

A idéia é simples, mas muitos desenvolvedores insistem em ignorá-la. Estou falando de código expressivo. Código escrito de ser humano para ser humano. Código que fala por si só. No nosso dia-a-dia sabemos que são raros os casos em que o encontramos. E a resistência é grande. Porém não podemos tapar o sol com a peneira, escrever código expressivo é uma tarefa que exige muito estudo e dedicação.

Normalmente não existe um incentivo natural para que isso aconteça. Infelizmente essa possibilidade, dentro de um projeto, recebe uma prioridade muito baixa. Primeiro busca-se obedecer e seguir a linha um calendário pré-estipulado. Depois tenta-se chegar aos requisitos. Uma boa apresentação. Um pouco de robustez. E, quem sabe, pode ser adicionada uma pitada de performance. E lá depois disso tudo, vem o cuidado em desenvolver um sistema com qualidade de código.

Hoje estima-se que mais de 60% do custo de um projeto de sofware é gasto com sua manutenção. Os benefícios ao buscarmos quebrar esse índice são fáceis de vislumbrar. É importante ressaltar que eles não são poucos. Facilidade na leitura coincide automaticamente com a facilidade de mudança. Quanto mais perto da linguagem de dominio o código estiver, mais pré-disposto a uma mudança ele estará, além de estar falando a mesma língua do usuário final do sistema. Além de trabalharmos com muito mais objetividade e altamente focados.

Muitos entendem que a melhor forma de programar está no “quanto menos melhor”. Outros depositam suas fichas nos comentários de códigos. Há ainda aqueles que apoiam-se em uma arquitetura em camadas (lêia-se muitas camadas). E existe espaço ainda para os diversos frameworks existentes no mercado. Colocamos nesse bolo, também, a sopa de letrinhas que aumenta a cada dia. É a síndrome da bazuca pra matar uma mosca perdida no ar.

Então é escolhido sempre o caminho mais difícil. Ao invés de simplificar, é preferível complicar. Ao invés de codificar o necessário, codifica-se o pior cenário. Complexidade acima da real necessidade, seja por prazer ou por qualquer outro motivo, é um mal que atinge muitos desenvolvedores. Esse mal costuma vir acompanhado pela aversão de testes. Resultando assim em um monstruoso código legado.

Hoje temos a oportunidade de trabalhar com linguagens de alto nível. Linguagens orientadas a objetos. Linguagens guiadas pela nossa realidade. Mas a insistência instintiva em continuarmos programando proceduralmente é alta. Hoje podemos nos dar ao luxo de deixar pra trás etapas que se consolidaram no desenvolvimento de software. A principal delas é a oportunidade de projetar o sistema diretamente em código, ao invés de em uma linguagem de baixo nível, quando precisavamos de artefatos como diagramas.

Para colocarmos o nosso código a falar precisamos estar focados em alguns aspectos importantes. Começando pela nomeação de qualquer coisa que você é criada. Acredite, isso é muito importante. Devemos estar atentos se o nome que a criatura irá receber está clara o suficiente para a representar. Vale fazer o teste se às duas horas da madrugada você entenderia o por que dela receber esse nome. A formatação de código, tarefa que hoje deixamos a cargo da nossa IDE preferida, é de suma importância para a boa leitura de código. É interessante a equipe toda aderir ao estilo de formatação único. Devemos sempre conhecer as convenções da nossa linguagem para seguir assim um modelo internacional de codificação. Assim como estar apto a identificar o uso de padrões de projeto. E usá-los. E o mais importante, na minha opinião, é focarmos em princípios de design como a responsabilidade única, não se repita (DRY), lei de demeter e muitas outras. E sem nunca esquecer que tudo isso deve ser dirigido e coberto por testes tão expressivos quanto o código final.

Talvez você gostaria de adicionar aí mais um item: comentários. Mas os comentários são um mal para o nosso sistema. Eles realmente não deveriam ser necessários. Mas como sabemos: muitos vezes se tornam um mal necessário. É nossa missão fazermos o melhor possível para eles não fazerem falta em um projeto.

Precisamos ter certeza que um objeto só pode ter uma única responsabilidade. Que um método, assim como um teste, só pode fazer uma única coisa. Que condicionais ternários, na maioria dos casos, são de dificil leitura humana. Que os nomes que damos as nossas criaturas (classes, métodos, variáveis…) devem ser pronunciáveis. Termos o cuidado em não duplicar código. Saber que métodos longos causam muitas redundâncias. Que quanto menos parâmetros passarmos em nossos métodos mais coeso está o nosso código. Evitar usar múltiplas saídas em métodos. E ter a consiência que a simplicidade é a nossa melhor forma de expressão.