Como escrever bom código?

Como programador, lembro-me do primeiro programa que escrevi. Lembro-me da diferença entre essas primeiras linhas de código e as que escrevo atualmente. Apesar de ficar surpreendido com a evolução natural da nossa escrita, não deixo de me perguntar porque é que muitos de nós não procuram evoluir constantemente na escrita de código? E porque razão quando chegamos a um determinado patamar, paramos de evoluir?

Tinha cerca de 16 anos quando passei a primeira instrução para um computador, foram algumas páginas em binário para um Zx Spectrum 128k. Foi viciante, desafiante e adorei. Recordo-me, sobretudo, de ser a minha primeira frustração. Largas horas a copiar código, sem que este funcionasse!

Passados estes anos todos, não deixei de adorar escrever código, procurando de forma constante evoluir nesta área e aprender técnicas para evitar o sentimento vivido na altura.
Partindo do pressuposto que a escrita de código tem uma influência maior na qualidade, quando comparado com requisitos ou testes, partilho algumas regras que trago na minha toolbox e deixo algumas perguntas para vos fazer pensar.

Quem é programador sabe que, passados alguns anos, terá inevitavelmente de manter código escrito por si ou por outros. Provavelmente já todos tivemos esta experiência, e provavelmente tivemos dificuldade de ler, manter e evoluir esse mesmo código. Também conhecemos a sensação de criar um problema ao tentar corrigir outro, dando origem àquilo que é vulgarmente conhecido por rot. A este código dá-se o nome de legacy code.

Assim, à medida que o código evolui, a cada adição ou modificação, a produtividade da equipa tende a descer. No limite podíamos dizer que a produtividade tende para zero.
Perante uma nova funcionalidade, uma das regras que mantenho é que o código tem de ser escrito com vista a ser mantido e, claro, a sofrer evoluções. Em relação ao código existente, recordo-me sempre da regra do bom escuteiro que sempre que se estabelece num terreno, "tem de o deixar mais limpo do que o encontrou". Podemos traduzir estas boas práticas numa regra simples: nunca baixar os requisitos relativamente à qualidade do código entregue.
 

O termo legacy code tem uma conotação negativa e pesada, visto que é entendido como código complicado, difícil de manter e de evoluir. Deparei-me com uma descrição, que apesar de ser discutível, refere que legacy code é apenas código sem testes.

Não posso deixar de concordar com o facto de que bom código tem de ser acompanhado, obrigatoriamente, de testes automáticos, sejam funcionais ou unitários. Os testes permitem a refatoração, mantendo funcionalmente as regras do código original, permitindo melhorá-lo sem receio de quem o programa. Para quem já esteve inserido numa equipa de testes automáticos, a minha sensibilidade para este assunto é clara e, em cada problema, avalio sempre do ponto de vista dos testes, a sua aplicabilidade.

Um princípio base é que equipas que escrevem bom código, conseguem garantir que o código novo não se torna legacy amanhã. O mesmo não se pode dizer para código escrito, visto que será difícil melhorar e manter.

Podemos falar de cultura, ou da falta dela, mas existe uma dificuldade em realizar pedidos de code review. Esta é uma forma de evoluir pessoalmente na escrita, permitindo-me:

Outras técnicas não passam apenas de menções honrosas que nem merecem um lugar fora do pódio, fazendo lembrar por vezes o serviço público, em que um programa e o outro aparentemente nada faz. A ideia é que, quando aplicadas de forma correta, estas técnicas servem para aumentar a produtividade e nivelar o conhecimento entre os pares, minimizando a introdução de problemas no código.

Afinal escrever bom código é uma arte, mas o que é isto de escrever bom código? Há uma definição que gostaria de destacar:

 
"Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone.”

A escrita de código é uma tarefa que deve ser realizada a pensar no próximo programador, no próximo tester e, em última instância, no cliente. O programador irá poder evoluir o código, o tester irá realizar testes com maior qualidade e o cliente usufrui de uma aplicação mais resiliente que pode incluir funcionalidades, sem quebrar as existentes.

Esta definição acabou por deixar de fora uma regra importante que envolve evitar a duplicação de código e que é o arqui-inimigo de quem escreve código e a principal causa de aumento da complexidade, riscos acrescidos e aumento de trabalho. O programador deve adotar a regra do preguiçoso ou do gago que ditam que "quanto menos código melhor”. A duplicação esconde, em muitos casos, problemas graves de arquitetura.

 

Cada programador tem as técnicas disponíveis na sua toolbox, e existem outros temas que também merecem atenção, desde a importância de saber fazer debug, até mecanismos de refactoring, assim como o famoso termo technical debt.

 

Considero que o programador tem uma influência maior na qualidade, do que qualquer outro papel dentro de uma equipa de desenvolvimento, e que a escrita de código tem uma importância vital no resultado final de um programa. É por isso que escrever melhor código é da responsabilidade de cada programador, para que se possa chamar um verdadeiro profissional. Não há desculpa para não fazer o melhor possível!