Boas práticas para escrita de métodos, funções e procedimentos - Parte 1 - Revista Engenharia de Software Magazine 39

Escrever código fonte é uma tarefa que depende de vários fatores, dentre eles podem-se destacar o conhecimento de uma linguagem de programação com suas estruturas e palavras reservadas e entender de lógica de programação. Um bom curso de programação pode proporcionar este tipo de aprendizado, ficando a cargo do aluno a tarefa de praticar o conhecimento adquirido desenvolvendo seus aplicativos.

Sabe-se também que a abstração é fundamental para que se possa modelar um problema e, consequentemente, definir as estruturas de código que transformarão o domínio em software. Nesse sentido, a tarefa de escrever código já se torna um pouco mais complexa, pois se pode ter dois desenvolvedores implementando o mesmo problema, mas devido a abstrações diferentes, existirem dois códigos distintos com o mesmo propósito.

A questão das diferentes abstrações sobre um mesmo domínio vem sendo discutida por diversos desenvolvedores, pois nesse ponto concentra-se um risco: como entender um código escrito por outro desenvolvedor a partir de uma abstração particular? Um código mantido por diversas pessoas de diferentes pontos de vista pode se tornar mais complexo?

Analisar e modificar códigos de terceiros, além de não ser, em alguns casos, uma tarefa simples, pode contribuir para que o código venha a se tornar mais confuso no decorrer do tempo, podendo chegar a um ponto que o custo de manutenção se torne mais alto que o custo do projeto.

Na contramão deste problema, existem técnicas, teorias, padrões e práticas, que tentam minimizar os efeitos que diferentes abstrações podem causar antes de se implementar um código ou depois do código já implementado, criando códigos mais fáceis de entender e manter, ou melhorando o código fonte existente.

A série de artigos sobre refatoração para padrões, que está sendo publicada desde a edição 28 da Engenharia de Software Magazine vem cumprindo seu objetivo que é o de propagar técnicas que podem contribuir para a melhoria do projeto de código existente (isto é, aumentar a qualidade do código) através da inserção de padrões de projeto por meio de refatorações (modificações no código de um software para melhorá-lo, sem remover nenhuma funcionalidade). Esta nova série de artigos por sua vez, discutirá os aspectos que permeiam o assunto Código Limpo, seguindo a linha de raciocínio que propõe um aumento na qualidade do código das aplicações existentes ou proporcionar conhecimento de como criar projetos de código melhores quando se está iniciando um novo projeto.

Cada empresa de desenvolvimento de software trabalha de uma forma: uns são adeptos da definição de pequenos padrões, que definem, a exemplo, como uma variável deve ser declarada, e outras que permitem que a escrita do código siga as práticas que o desenvolvedor estiver acostumado a utilizar. A definição de padrões para melhorar a qualidade do código fonte e criar uma formalização entre os responsáveis por escrever software nas empresas também será assunto desta nova série sobre código limpo.

Código bom ou código ruim

Uma importante literatura técnica sobre código limpo (MARTIN, 2009) compara manutenção em software com código bagunçado e de difícil leitura a atravessar um local cheio de lama e com muitos arbustos emaranhados que escondem armadilhas. O fato é que um código deste tipo pode ser considerado um código ruim. Outra importante literatura técnica sobre projeto de código, entre outras coisas, (KERIEVSKY, 2008) relata que escrever código que possa ser entendido e executado por uma máquina é fácil, todavia escrever código que possa ser lido e entendido por humanos é bem mais complexo. Classificar um código como ruim ou bom é uma tarefa que exige análise e entendimento do código em questão. Por sua vez, se tal código não puder ser entendido por ser muito confuso, classificá-lo como um bom código não será possível.