Há 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 acrescentamos complexidade sem necessidade.
Quando você está indo a um lugar qualquer e encontra um atalho, você segue por ele?
Imagem via Shutterstock
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 intenso. No fim das contas, 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, em um RPG, 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 enganei: os meus personagens não eram fortes o suficiente 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á que 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.
A maior vantagem de escrever um código compreensível é, 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.
Por outro lado, trazer objetividade para um código pequeno não significa escrever linhas duplicadas, utilizar variáveis demasiadamente 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” ou “provisório”. 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 anteder, ele certamente ficará frustrado com a qualidade do serviço feito pela outra pessoa. No pior dos casos, ele terá que 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. Portanto, vamos praticar Clean Code!
Obrigado, leitores!
Publicado originalmente no blog SubRotina
8 Comentários
Concordo com você. Sou desenvolvedor já há alguns anos e quando comecei, tentava de todas as formas usar funções prontas da linguagem que utilizava na época. Meu superior, vivia dizendo para evitar isso e utilizar o modo simples ou como dizia: fazer o “feijão com arroz”.
Hoje entendo perfeitamente o que ele dizia na época. Pegando projetos mais complexos, vejo hoje as pessoas sugerindo soluções complexas e cada vez mais inviáveis.
Com a experiência adquirada com o passar dos anos, compreendo que o simples com certeza sempre será a melhor forma.
Ótimo comentário, Fernando. Eu tive essa mesma experiência. Hoje reconheço a importância da simplicidade e eficiência no código. Como dizia o Robert C. Martin:
“Tornar seu código legível é tão importante quanto torná-lo executável.”
Obrigado!
Parabéns pelo post.
Apenas complementando, um exemplo disso que foi mostrado no post são as funções recursivas que nos ajudam a ter um código menor, porém tem um custo maior de execução pois consomem mais memória. Ja presencei casos assim.
Concordo, Johni. Há vários recursos na programação que colaboram para reduzir o código, e funções recursivas é um deles. No entanto, devemos nos atentar pela simplicidade e legibilidade do código. Se a função recursiva for muito complexa, é possível que comprometa a compreensão do método.
Obrigado pelo comentário!
Não sou muito de comentar em sites, mas tenho que te dar os parabéns pelo post.
Sou apenas um iniciante nessa vida de programador, mas uma coisa eu garanto, vou levar esse texto comigo pro resto da vida.
Legal, Rodolpho! Essa é justamente a intenção: instruir novos programadores para se tornarem profissionais de qualidade.
Obrigado pelo comentário!
No início da carreira, eu tinha fixação por códigos menores, o que incluía variáveis de nomes curtos e/ou abreviados, além de tabelas e colunas em siglas. O tempo passa e descobrimos o quão difícil é retornar e dar manutenção. A lição vem definitiva quando precisamos dar manutenção em códigos de outros profissionais com o mesmo mau hábito. Felizmente aprendemos com o tempo. Adoraria ter lido mais artigos como este anos atrás.
Ótimo depoimento, Fernando.
No início da minha carreira como programador, eu também tinha o mesmo pensamento.
O que fez mudar o meu mindset, (além, claro, da experiência com desenvolvimento colaborativo), foi a leitura do livro Clean Code do Robert Martin, no qual considero um material mandatório para programadores. Neste livro, o autor explica a importância de escrever um código expressivo ou “auto-explicativo”, capaz de fazer com que qualquer programador entenda o seu objetivo.
Obrigado pelo comentário! Abraço!