CODEsign: Faça duas vezes!

E aí, pessoal, tudo certo?
Há algumas semanas, compartilhei um dos artigos do blog em um dos grupos de Clean Code do LinkedIn e recebi alguns comentários na publicação. Um dos membros, chamado Max Kleiner, mencionou uma técnica bem bacana que pode colaborar com a escrita de código limpo. Trata-se do CODEsign. Leia o artigo e conheça as propostas dessa técnica!

Introdução

Como de costume, para facilitar a associação do termo, vale apresentar um exemplo logo de início.

Suponha que você desenvolveu, pela primeira vez, um aplicativo para exportar um conjunto de dados para uma planilha do Excel. Durante o desenvolvimento, você estudou e utilizou bibliotecas de I/O para gravar arquivos e algumas funções para trabalhar com exportação de dados. Perfeito.

Agora, faço uma pergunta: se fosse necessário desenvolver o mesmo projeto novamente, você faria diferente?

Eu aposto que sim!

A proposta do CODEsign

Levando em conta o conhecimento que você adquiriu desenvolvendo o projeto na primeira vez, é bem provável que, ao implementá-lo pela segunda vez, o código ficaria bem melhor. O motivo é óbvio. Com base na experiência anterior, aprimora-se a capacidade de elaborar algo mais profissional. O simples fato de criar um método com um nome mais expressivo já traz um aspecto mais profissional ao código.

Essa é a ideia do CODEsign: implementar a mesma funcionalidade duas vezes! Considera-se que, na segunda vez, há uma possibilidade significativa de escrever um código mais limpo. Você, desenvolvedor, já deve ter passado por essa experiência e sabe do que estou falando. 🙂

Coincidentemente, isso aconteceu comigo há alguns dias. Desenvolvi um miniprojeto para ler um arquivo texto e importar o conteúdo para uma base de dados (semelhante a um processo de ETL), porém, depois de finalizado, mesmo funcional, não fiquei satisfeito com a quantidade de linhas e com a estrutura do código. Decidi refazer o projeto, mas, como já tinha conhecimento das deficiências da primeira tentativa, considerei formas diferentes de escrever o código, e o resultado foi surpreendente! Criei uma classe de leitura herdando de estruturas nativas e declarei vários métodos que antes haviam sido repetidos, melhorando não só o código, mas também a arquitetura.

Na prática, apliquei o CODEsign! 🙂

Como o conceito do CODEsign é relativamente amplo, decidi reunir as partes mais voltadas para programação e aproveitei para acrescentar um pouco do meu conhecimento nessa ideia.

Para ter um efeito realmente satisfatório, o CODEsign consiste em ponderar cinco aspectos ao reescrever a funcionalidade, detalhados a seguir.

1) Simplicidade

Reflexão: “Existe uma forma mais simples de implementar a funcionalidade?”
Pode parecer óbvio, mas muitas vezes a simplicidade passa despercebida. O código abaixo faz a leitura de uma string e exibe os valores que estão separados por vírgula (nome, sobrenome e cidade):

Hmm… o código ficou confuso, não?

Se pesquisarmos na documentação da linguagem, ou mesmo na internet, é possível encontrar funções exclusivas (e, claro, mais simples) para essa finalidade, poupando toda a complexidade criada anteriormente:

2) Performance

Reflexão: “Existe uma forma mais rápida de executar a operação?”
Considere o código abaixo. Para cada produto, há um cálculo de desconto:

A condição IF é realmente necessária? Imagine que, de 1000 produtos, apenas 200 deles possuem valor maior que zero. 800 iterações do loop de repetição seriam, na prática, em vão. Se aplicarmos um filtro antes do loop, teríamos um ganho considerável de performance:

3) Integridade

Reflexão: “O código está suscetível a erros?”
O código a seguir carrega o conteúdo de um arquivo dentro de um componente TMemo:

Ops, mas espere aí… se o arquivo não existir, ocorrerá uma exceção. É nosso dever garantir a integridade da execução do aplicativo.

4) Confiabilidade

Reflexão: “O código é capaz de tratar exceções e se recuperar de falhas?”
Dessa vez, o método abaixo faz o download de um arquivo em um diretório FTP para o computador:

Primeiramente, o que acontecerá se a conexão com a internet for interrompida durante o download? Em segundo lugar, é importante garantir que a conexão FTP seja fechada após a transferência do arquivo. Estes eventos podem ser solucionados com os tradicionais try/except e try/finally:

5) Redundância

Reflexão: “É possível evitar a duplicação de código?”
Algumas vezes, a redundância no código pode prejudicar a leitura do código. Veja o exemplo abaixo:

Notou a quantidade de vezes que o FieldByName é utilizado? Para evitar essa redundância, podemos declarar uma simples variável:

Pessoal, os exemplos são bem básicos, mas suficientes para trazer um pouco da didática do CODEsign. Na prática, ao codificar uma funcionalidade pela segunda vez, além dos aspectos acima, o desenvolvedor pode descobrir novas abstrações, resultando na criação de novos componentes, bibliotecas ou classes, como foi o meu caso.

Creio que você já tenha se deparado com um projeto antigo e pensado: “Nossa, que código feio. Hoje eu faria completamente diferente…”, não é? Tecnicamente, não deixa de ser a prática do CODEsign! 🙂

Até a próxima, pessoal!