Por Mayra Michels, consultora de CRM e Desenvolvimento de Software da Via Consulting
Imagine a seguinte situação: um desenvolvedor procurando um bug em uma função na qual não foi ele quem desenvolveu, às 19 horas de uma sexta-feira, sendo que a aplicação entrará em produção no dia seguinte. Encontrar uma situação dessa, com um código ilegível, e demorar um bom tempo para compreender sua lógica e regra de negócio não é tão incomum.
Mas a prática do dia a dia nos impõe desafios. Um deles é o prazo, que na maioria das vezes é apertado e nem sempre é pensado no tempo de algum erro ocorrer. Com o desafio de entregar na data solicitada (ou não estourá-la demais), acabamos tornando o código “prático”, passando, então, a ter muitos erros.
Ao escrever um código, é necessário ter em mente que outros programadores irão mantê-lo. Como disse Chad Fowler, famoso desenvolvedor de software, “um bom programador escreve o código para outros programadores, e não para máquinas”.
Com o tempo, o custo de desenvolvimento e manutenção do projeto aumenta, ficando cada vez mais inviável criar novas funcionalidades e realizar qualquer tipo de modificação, sem falar na quantidade de defeitos. Esse tipo de problema, além do prejuízo financeiro, pode ainda afetar a imagem da empresa no mercado.
Em 1982, James Q. Wilson e George L. Kelling escreveram um artigo muito conhecido, chamado “Janelas Quebradas”, que dizia o seguinte: “Pense em um edifício com apenas algumas janelas quebradas. Se as janelas não forem reparadas, a tendência é que vândalos quebram mais janelas. Eventualmente, poderão inclusive entrar no edifício, e se este estiver desocupado, pode ser tomado ou até mesmo incendiado”.
Como uma analogia ao artigo de Wilson e Kelling, no desenvolvimento de software, se o código está ruim, o projeto não tem testes, comentários, as exceções não são tratadas de forma correta e os nomes das classes não referenciam as regras que executam, a tendência é que os novos desenvolvedores não tenham a mínima vontade de melhorar e continuem programando da mesma forma, agravando ainda mais a situação.
Com esses cenários, o melhor é sempre procurar escrever códigos limpos e manter a boa prática da programação. Alguns dos princípios básicos da boa prática são:
• Escolher bons nomes para as variáveis e funções. Nomes significativos e que estejam de acordo com o contexto empregado são tão importantes quanto todo o código escrito.
• Uma função deve fazer apenas UMA coisa. Uma função que desempenhe mais de uma tarefa, a torna muito complexa e sua compreensão difícil.
• Comentar o código. Os comentários servem para explicar o código, ajudando o próprio desenvolvedor a lembrar do que se trata a função, como também outros desenvolvedores a darem manutenção no código.
• Coesão. A coesão representa o quão uma classe é específica para desempenhar um papel em um contexto.
Princípios como esses ajudam a desenvolver códigos com maior qualidade, tendo assim mais produtividade, influenciando na facilidade da manutenção. A boa prática não é complexa, basta começar a fazer que facilmente se pega o hábito, tornando o trabalho mais simples e permitindo que o foco seja no que realmente importa, que é o desenvolvimento da aplicação, ganhando tempo e, por consequência, dinheiro.
Como uma recomendação de leitura, o livro “Código Limpo“, de Robert C. Martin, trata a fundo sobre os pontos considerados indispensáveis para que se possa escrever um código bem feito e funcional.