O dia em que percebi que tinha senioridade
Por anos evitei projetos em Node. Até pegar um legado em produção e perceber que o que me destravou não foi a linguagem, foi o padrão por baixo dela. Sobre o que isso me ensinou de senioridade, e o que ainda me falta.
Até 2019, Node era uma coisa que eu evitava. Não por birra técnica, mas também (hehe). Eu era fluente em Python e Django, e a minha função principal nunca foi só programar: era tocar o negócio e desenhar soluções. Ficar dentro da stack que eu conhecia me dava segurança. Fora dela, eu questionava se sabia o suficiente.
Aí eu peguei uma aplicação legada, com backend em Node, rodando em produção, que precisava de mudanças. Eu tinha que entender como aquilo funcionava.
Como eu destravei
Abri o projeto sem saber por onde começar. A primeira coisa que reconheci foi um model, a parte que representa os dados e conversa com o banco. Do model, cheguei nas views, a parte que monta o que volta para quem pediu. E aí caiu a ficha: aquilo era MVC. Depois achei os routers, que dizem qual código responde a cada endereço, exatamente no papel que o urls.py tem no Django.
A partir desse fio, o nó foi desatando. A sintaxe continuava estranha para mim, mas eu sabia onde procurar cada coisa. Quando aparecia um erro, eu sabia em que camada ele provavelmente estava. O que pensei na hora foi mais ou menos isso: agora que eu sei isso, posso mexer em qualquer linguagem.
O padrão era de arquitetura, não de linguagem
Eu conhecia o MVC desde o segundo ano da faculdade, em 2007, e trabalhava com ele todo dia no Django. O que eu não tinha percebido até aquele dia era o tamanho da coisa: o padrão importava mais do que a linguagem. Ele não pertencia ao Django. Era de arquitetura, e o Django era só um dos jeitos de escrever aquilo. O projeto em Node era outro.
Anos depois, a mesma coisa aconteceu com um sistema legado em Java. O raciocínio já veio quase sozinho, como uma sequência de perguntas: se isso é um sistema, ele lida com banco de dados. Se lida com banco, provavelmente tem um ORM. Se tem ORM, provavelmente é um MVC de algum jeito. Se é MVC, em algum lugar tem um model, em algum lugar tem uma view, e alguma coisa faz o papel do controller. Então o trabalho é achar essas caixinhas primeiro e só depois entrar no código de cada uma.
Não quer dizer que tudo ficou fácil. Muitas vezes a dificuldade não estava na técnica, estava no problema que o software resolvia: uma regra de negócio complicada é complicada em qualquer linguagem. Mas saber onde as coisas moram tira o medo de abrir o projeto.
Nem todo padrão ajuda
Também já peguei o contrário: projetos em que o MVC tinha virado camada dentro de camada dentro de camada, e seguir o fio não levava a lugar nenhum. Reconhecer o padrão ajuda justamente porque ele é simples. Quando alguém empilha abstração sem necessidade, o mapa some.
Eu lembro de um professor que repetia sempre a mesma coisa quando alguém queria criar mais uma camada: "tu não vai precisar disso". Demorei para dar o valor que essa frase tem.
Às vezes o problema nem é de camada, é de dado. Um caso que ilustra bem: um sistema legado de venda de ingressos guardava tudo num banco NoSQL de documentos. Documento funciona bem quando a informação é lida e gravada junta, como um carrinho de compras ou um perfil. Ingresso não é assim: tem evento, lote, compra e participante, e tudo se relaciona com tudo. O front-end tratava esses dados de forma estruturada, como se cada coisa tivesse o seu lugar, mas no banco estava tudo junto e repetido. Os dados do participante, por exemplo, apareciam dentro de cada compra. Para corrigir um e-mail, era preciso atualizar o mesmo dado em vários documentos, e bastava esquecer um para o sistema passar a ter duas versões da mesma pessoa.
Ali o padrão que faltava não era de código. Era perceber que aquela informação era relacional por natureza, e que o banco tinha sido escolhido para um formato de dado que o sistema não tinha.
O que me faltava
Tem um lado menos confortável nessa história. O meu conhecimento técnico foi construído quase todo na prática, fazendo, errando e corrigindo em projeto de cliente. Eu tinha pouco dos fundamentos clássicos, dos livros que todo mundo cita. Reconheci o MVC no Node porque já tinha visto aquilo dezenas de vezes em outros sistemas, não porque tinha estudado a teoria por trás.
Estou lendo e relendo esses clássicos agora, e a sensação é curiosa. Muita coisa eu já fazia sem saber o nome. A experiência me deu o reconhecimento; a teoria está me dando as palavras e alguns corretivos. Uma não substitui a outra.
O que eu chamo de senioridade
Se eu tivesse que resumir o que mudou naquele dia, seria isto: senioridade não é dominar a tecnologia X. É conseguir olhar para um sistema que você nunca viu, numa linguagem que você não domina, e reconhecer o que está por baixo dele. Esse reconhecimento não vem de curso. Vem de ter visto muitos sistemas, bons e ruins, e de ter se perdido em vários deles antes.
É também por isso que me preocupa quem vai formar o próximo sênior. O que me destravou no Node foi um repertório que eu só tinha porque passei anos abrindo código dos outros e apanhando dele.