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?
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 desenvolvedoresescrevam 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!
Fonte: profissionais TI
Fonte: profissionais TI
Faça Comentario pelo Blogger
Faça Comentario pelo Facebook