Código pequeno nem sempre é a melhor opção

Código pequeno nem sempre é a melhor opçãoHá alguns anos, um professor me disse que quanto menos linhas houver em um código, mais rápido ele será compilado ou interpretado. Concordo com ele… em partes! Algumas vezes, na busca de reduzir demais o código, criamos problemas paralelos ou complexidades sem necessidade.
O primeiro artigo de 2014 visa discorrer sobre este assunto. Off we go!

 

Quando você está indo a um lugar qualquer e encontra um atalho, você segue por ele?
Certa vez, enquanto estava indo ao shopping, decidi usar um atalho que me ensinaram para chegar mais rápido, embora eu ainda não o conhecesse. Quando entrei no atalho, me deparei com várias ruas esburacadas, alguns trechos em obras e um trânsito enorme. Parece que todos naquele dia decidiram seguir por este atalho. Conclusão? Levei muito mais tempo pra chegar ao shopping, me refletindo a história de que “nem sempre o melhor atalho é o melhor caminho”.
Outra vez, eu estava jogando um RPG e descobri uma forma de “pular” 6 fases do jogo. Achei o máximo, porém, na ilusão de que eu ia terminar o jogo mais rápido, me enrolei: o nível de experiência (EXP) dos meus personagens era muito fraco para enfrentar os inimigos daquela fase. Tive que voltar. Neste caso, o atalho deu certo, mas o problema foi a consequência de tê-lo usado.

 

Durante os anos, comecei a notar o quanto isso se assimila com o código que escrevemos. No desenvolvimento de software não há atalhos, mas existem formas de reduzir o código que nem sempre trazem uma melhor qualidade ou uma compilação mais rápida. Ao optar pelo caminho mais curto, é possível que você se esbarre em complicações e leve mais tempo para implementar um código, ou, talvez, terá de refazê-lo. E mais, se você criar um código instável somente por ser mais rápido, talvez poderá dificultar a leitura nas próximas “fases” do projeto.

Como exemplo, o código em Delphi abaixo faz a busca de um valor em um arquivo INI de acordo com a seção e a chave indicada em campos de texto:

editValor.Text := TIniFile.Create(ExtractFilePath(Application.ExeName)
  + 'Arquivo.ini').ReadString(Trim(editSecao.Text),
  Trim(editChave.Text), '');

É desconfortável ler essa linha, não?
Seria bem mais fácil, limpo e simples se o código estivesse dessa forma:

var
  ArquivoINI: TIniFile;
  Caminho, Secao, Chave: string;
begin
  Caminho := ExtractFilePath(Application.ExeName) + 'Arquivo.ini';
  ArquivoINI := TIniFile.Create(Caminho);
  Secao := Trim(editSecao.Text);
  Chave := Trim(editChave.Text);
 
  editValor.Text := ArquivoINI.ReadString(Secao, Chave, '');
 
  ArquivoINI.Free;
end;

 

Você aumentou quase 10 linhas no código!
Sim, justamente para facilitar a compreensão. Veja que cada linha é claramente entendida e tem um propósito único. A maior vantagem de escrever o código dessa forma é, sem dúvidas, contribuir para a atividade de manutenção. Se você trabalha em uma empresa de desenvolvimento de software, lembre-se de que outras pessoas irão realizar manutenções no seu código, portanto, quanto mais objetivo estiver, menor será o tempo de interpretação e menos o programador irá chamá-lo para esclarecer possíveis dúvidas. Sendo assim, do mesmo modo que você espera que outros desenvolvedores escrevam um código limpo, você também deve fornecer essa facilidade. Isso é ética profissional.

 

Mas, no ano passado…
Sim, já sei o que você está pensando. No ano passado publiquei um artigo sobre código legado que aparentemente contradiz com o que estou dizendo aqui, mas observe que há um parágrafo naquele artigo afirmando que a redução do código pode trazer vulnerabilidades ou dificuldades na interpretação. E, claro, não é isso que queremos que aconteça!
Por outro lado, trazer objetividade para um código pequeno não significa escrever linhas duplicadas, utilizar variáveis em excesso ou códigos dispensáveis. É necessário um equilíbrio. Se você está repetindo linhas de código que podem ser refatoradas ou utilizando várias estruturas de repetição e condicionais aninhadas, o código será razoavelmente interpretável, mas não estará limpo. Na verdade, a leitura do código se torna cansativa.
O ideal é escrever o código já pensando que outra pessoa provavelmente terá que interpretá-lo futuramente. Aliás, você mesmo pode voltar nesse código após um tempo.

 

Pensando por um lado mais profissional, escrever código bem feito revela a qualidade do seu trabalho. O código pode não ser diretamente visível para o cliente (já que o código é embutido no arquivo compilado), mas é notável pelos colegas de trabalho e pelos superiores. Em uma analogia, compare essa atividade com o trabalho de um mecânico de automóveis. Considere que ele tenha resolvido o defeito do seu carro, mas de um modo paliativo (vulgo “gambiarra”). O carro funciona, mas pode dar o mesmo defeito a qualquer momento. Se você o levar na mesma mecânica e outro técnico lhe atender, ele certamente ficará frustrado com a qualidade do serviço que o seu colega de trabalho fez. No pior dos casos, ele terá de refazer o trabalho.
Programação de software é bem semelhante. Em algum momento o seu código será lido por outro profissional, mesmo que por fins de compreensão da regra de negócio.
Escrever um bom código é uma arte do profissional de desenvolvimento e pode trazer inúmeros benefícios, como aumento da produtividade, redução de complexidade e até mesmo uma promoção na empresa, dependendo das circunstâncias.

 

Você deve ter notado que utilizei a expressão “código limpo” em alguns pontos do artigo. Essa expressão vem da técnica de Clean Code, mencionada na parte 9 do artigo sobre dicas para desenvolvimento. A minha intenção é elaborar alguns artigos sobre este assunto, baseados no próprio livro Clean Code de Robert C. Martin e em alguns materiais encontrados na internet.

 

Por hoje é só, leitores.
Até a próxima semana!


 

Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.