Refatorando código legado em projetos React — Parte V
Chega o fim desta longa jornada:
- Introdução, primeiros passos e teste de integração
- Refatoração, teste de unidade, testando e refatorando componentes
- Projetos do mundo real
- Redux
- Você está aqui! 🚩
Para fechar com chave de ouro, esta série termina com algumas conclusões sobre qualidade de software, com alguns mitos e verdades que precisam ser esclarecidos para evitar a criação de novos projetos legados.
Qualidade vs Velocidade
Comumente estamos acostumado a escutar que não há tempo para fazer testes pois há um prazo apertado para entrega do projeto, principalmente aqui no Brasil. Há dois grande motivos por isso ser frequentemente falado:
- Fazer algo desconhecido realmente leva mais tempo. Entregar um projeto em uma tecnologia já conhecida com certeza é mais rápido que com uma tecnologia desconhecida, o mesmo acontece com os testes, lint e demais ferramentas de qualidade, se o desenvolvedor vai ter que fazer algo novo que não está acostumado a fazer vai ter um impacto grande na entrega.
- Falta de visão a longo prazo. Escrever testes e utilizar ferramentar de checagem e monitoramento dá uma falsa sensação de trabalho extra e que isso vai impactar na velocidade final de entrega, mas é aquela história do lenhador, quanto mais afiado o machado, maior a quantidade e maior a velocidade de árvores cortadas. Como Uncle Bob tuitou, a única forma de ir rápido é ir do jeito certo:
Mudança de tecnologia
A área de desenvolvimento de software é relativamente nova, mas está em crescimento exponencial, e é natural querermos acompanhar essa evolução usando paradigmas e ferramentas novas, mas comumente esta decisão é tomada pelos motivos errados.
Se a deficiência está no(s) desenvolvedor(es), mudar a tecnologia do projeto não irá resolver o problema, irá apenas trocar de problema. Se você dirige um carro por muito tempo, talvez trocar de carro te deixe mais animado e resolva seu problema, mas se o problema está no percurso, se você está cansado de dirigir ou se você simplesmente dirige mal, trocar de carro não irá resolver seu problema.
Qualidade vale o preço?
Martin Fowler levanta boas questões sobre este tópico no artigo “Is High Quality Software Worth the Cost?” e chega a conclusão que software de alta qualidade é mais barato de produzir. Se é mais barato, por que constantemente abrimos mão dela?
Todas as decisões são tomadas por pessoas, por melhor que seja a tecnologia que temos hoje, o fator humano ainda é o fator de maior peso no resultado final. Bons profissionais são caros, e infelizmente (paras empresas) tem mais demanda do que oferta, então o que já é caro se torna ainda mais caro.
Ainda no mesmo artigo Martin Fowler menciona:
Countless times I’ve talked to development teams who say “they (management) won’t let us write good quality code because it takes too long”. Developers often justify attention to quality by justifying through the need for proper professionalism.
Um profissional ruim sempre irá transferir a culpa, o problema está na gestão ou na tecnologia, nunca com ele mesmo.
Mas tenho uma boa notícia para lhe dar. Se você, meu caro leitor, está comigo deste a Parte I desta série de artigos, você é parte da solução deste problema, pois está procurando e estudando sobre melhores práticas. O único caminho para um bom profissional é através do conhecimento, faça do estudo um hábito diário.
Compartilhar conhecimento também é uma forma de aprender. Eu tive que revisitar muitos conteúdos, procurar referências novas e me atualizar para escrever estes artigos, com certeza aprendi muito neste processo. Quanto mais eu tento ensinar, mais eu aprendo.
Conclusões finais
Gostaria de fazer um agradecimento aos colegas e amigos com quem trabalhei na M4U, foi uma experiência incrível com muito aprendizado e boas risadas, em especial a galera da M4U Tech que revisou e contribuiu na construção desta série de artigos.
Um grande aprendizado que vou levar comigo é que não importa se você é sênior ou júnior, não importa quanto tempo você está nesta carreira de desenvolvimento de software, entregar com qualidade não é uma questão de experiência, é uma questão de atitude. O conhecimento só vem para quem o busca.
