Quando escrevi o meu primeiro código executável (Visual Basic 3.0 em 1997) me perguntei se o havia feito do jeito “certo”, se era legível, se outras pessoas entenderiam, enfim, questionei-me se havia escrito o código da melhor maneira possível.

Já se passaram 12 anos desde então e eu ainda tenho essa dúvida! Incrível, não ? Mas acho que isso é algo que levarei comigo para o túmulo. Evidentemente há várias técnicas para melhorar a qualidade (caramba, não queria utilizar esta palavra) do seu código. Ultimamente tenho estudando bastante isso e me forçado a não me corromper com códigos ruins, por conta de prazos apertadíssimos. Eis que cheguei em algumas conclusões:

  1. Tente não violar a Lei de Demeter. Se você ainda não compreender a beleza por trás da sua simplicidade, não tem problema você pode segui-la mesmo assim, ou dar algumas cabeçadas e ver que o problema todo é que suas classes falam com muitas outras que não deveriam.
  2. TDD! Ok, isso é polêmico, mas pense assim: Quando você se utiliza de TDD, você se torna o primeiro cliente do seu código, e acredite, você vai querer mudar bastante suas interfaces para agradar a você cliente.
  3. Já que falei de interfaces, lembre-se: “Programe para interfaces!!!!” (ok, 4 exclamações acho que basta =p ).
  4. Codifique pensando no teste (unitário) e teste pensando no código. Se a criação dos testes estiver se tornando uma tarefa árdua, há algo de errado no seu design ;-)
  5. Nunca se acomode com o design de suas classes. Acredite, sempre pode ser melhorado.

Acho que consegui resumir o que ando fazendo para tentar melhorar o meu jeito de codificar, de forma que a manutenção do código que eu escrevo não seja tao árdua. E agora, para finalizar, uma frase do Martin Fowler que eu adoro:

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

E é isso o que estou perseguindo. Um dia eu chego lá.