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 complexidades sem necessidade.
O primeiro artigo de 2014 visa discorrer sobre este assunto. Off we go!
Introdução
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 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.
Exemplo
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:
|
1 2 |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
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.
O ideal, na verdade, é 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.
Qualidade do trabalho
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 (para não dizer “gambiarra”, haha). 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, no qual já existe um artigo aqui no blog. A minha intenção é elaborar mais 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!