Olá! Espero que esteja bem, independentemente do fuso horário em que esteja. Queria compartilhar um pouco da minha experiência nos últimos seis meses, quando trabalhava em um hospital. A situação lá era desafiadora, principalmente devido à arquitetura de software. Posso dizer sem rodeios que era um verdadeiro desastre. Era difícil implementar qualquer mudança significativa; muitas vezes, acabávamos apenas refatorando códigos que logo voltavam a dar problemas.

Inicialmente, eu tinha boas intenções: Queria melhorar a arquitetura do software, estabelecer práticas de código mais eficientes e introduzir revisões de código, que são essenciais até mesmo em projetos pessoais. O pair programming também era uma ideia que considerávamos genial, pois poderia contribuir significativamente para o trabalho em equipe.

Entretanto, o maior obstáculo era a minha equipe. Tínhamos um colega sênior de 51 anos que pensava saber tudo, mas na verdade tinha pouco conhecimento tanto de back-end quanto de front-end. Eu constantemente sugeria ideias para melhorar, como migrar o template do front-end de React 15, que usava bootstrap com sintaxe JS pura e componentes de classe, para React 18 com Typescript, SWC, Vite e criação componentes funcionais utilizando os ganchos do React, além de adotar bibliotecas auxiliares como Axios, React Router Dom, Yup ou Zod, e React Hook Form ou Formik.

Me lembro que quando cheguei, apresentei a sintaxe JSX para eles. E, Sabe como é entender algo que não faz sentido inicialmente, mas depois parece tão óbvio? Foi exatamente assim que eles se sentiram ao ver a sintaxe JSX. (1 ponto pra mim)

Para complementar a mudança, eu estava desenvolvendo um Design System, que seria posteriormente transformado em uma biblioteca de componentes prontos feitos com Styled Components ou TailwindCSS. Acreditei firmemente que essa abordagem não apenas melhoraria a qualidade e a eficiência do nosso software, mas também tornaria o desenvolvimento e a manutenção muito mais suaves e escaláveis no futuro, pois séria feito de modo modular, escalável e fortemente customizável.

No que diz respeito ao back-end, propus migrar do Node.js 14 para o Node.js 16^ com Typescript, substituindo o framework que era o Express para o Fastify, e adotando outras ferramentas como nodemon, cors, morgan juntamente com Testes Unitários, (Nossos Bancos de dados eram OracleDB e Postgres). A sugestão incluía a adoção de classes para facilitar o desenvolvimento, já que muitas partes do código eram complexas e difíceis de manter. E também para deixar o back-end escalável, modular e fácil de dar manutenção.

Em resumo, as pessoas que não querem evoluir simplesmente serão contra tudo aquilo que esteja relacionado à evolução. Quando quiserem mudar algo, acabarão fazendo uma revolução que causará danos mais críticos do que se pode imaginar, como quando a aplicação quebrou em plena reunião para os diretores. As ideias de melhorar processos e práticas jamais serão ruins. Infelizmente, não consegui fazer isso no meu trabalho passado, pois, com apenas 19 anos e sem faculdade, era complicado. Mas tudo isso mudou quando o chefe do meu irmão me contratou como Engenheiro de Software Front End em uma das 10 maiores empresas do Brasil. Toda a orientação que apresentei em diversas PoCs e MVC para meus antigos colegas de trabalho me levou a estar onde estou hoje. Não me arrependo de nada, ajudei como pude, propus ideias, melhorias de processos, autonomia em grande escala. Mas não controlo pessoas. Devemos apenas aceitar, mas caso queira persistir, é algo que nunca deixei de fazer. Quem sabe, uma hora talvez você consiga, mas vai ser bastante estressante e frustrante.