Programar usando boas práticas é um exercício de empatia
Você QA (ou dev) já parou para pensar nisso?
Escrever um código que o computador consiga entender e executar é “fácil”. Mesmo implementações nada elegantes podem funcionar de forma minimamente satisfatória (as famosas “gambiarras”).
Mas quem vai evoluir e sustentar o software ao longo do tempo? Humanos!!! Não deveríamos então nos preocupar em garantir que este código seja compreensível por humanos? Afinal, são eles que dão vida ao software e o mantém. E muitas vezes, quem precisa alterar o software não é a mesma pessoa que o desenvolveu.
Quem já se deparou com um código excessivamente complexo, acoplado, sem documentação nenhuma sabe bem do que estou falando. Imagina ter que alterar coisas ali dentro! É caminhar em um campo minado.
Mas também há o outro lado da moeda: quem nunca fez aquele código macarrônico que funcionou em algum momento do passado, voltou a olhar pra ele e se perguntou “o que eu fiz aqui???”
É aqui que entra a empatia.
Sempre que escrever um código (seja você dev ou QA) coloque-se no lugar dos seus colegas: será que eles vão entender o que você implementou? Será que você mesmo vai entender o que você implementou daqui uns meses? Será que se for preciso fazer mudanças aqui acontecerão catástrofes?
Estudar design patterns e boas práticas de programação e aplicá-las sempre que possível é sim um exercício de empatia com os seus colegas e com “o você do futuro”! Todos ganham.
Construir um software do zero é “fácil”. Difícil é evoluir, adaptar e manter o software funcionando em produção. Mudanças sempre vão acontecer ao longo do ciclo de vida de um software.
Precisamos fazer o nosso melhor para que elas causem a menor quantidade de efeitos colaterais indesejados possível. Isso é válido tanto para desenvolvimento de software quanto para automação de testes.
Pense nisso ;)
