Já parou pra pensar em quantas tecnicas, frameworks, linguagens são “lançadas” toda semana? Você deveria conhecer todas elas? Claro que não! O mundo de TI muda muito mais rápido do que qualquer um de nós pode conhecer. Não conseguir estudar alguma tecnologia não faz de você um profissional ruim.
Talvez por isso é muito comum que quando uma grande empresa divulgue a sua stack, ou alguma técnica especifica, o boom desse conteudo seja surpreendente, e em alguns meses, todo mundo que conhecemos utiliza a mesma stack para os problemas do dia-a-dia. Confiamos nessas empresas, as temos como referencia e se elas utilizam algo, aquilo deve ser bom, certo? Mais ou menos…
É bem ai que começa o problema, o que torna a maioria das coisas boa ou não, é a sua utilidade. Para que o que é bom para o Facebook seja bom pra nós, temos que nos comparar ao Facebook, e sejamos sinceros, nem todo mundo trabalha no Facebook! 😉
O que importa então? Como podemos escolher o que usar? O segredo é: CONTEXTO. Se a Netflix utiliza microservices, eu deveria? Qual a minha situação atual? Eu realmente preciso de todo o overhead? Será que preciso escalar tanto quanto eles?
Quando a Spotify publicou seu modelo de trabalho, conhecido hoje como modelo Spotify, não demorou muito para que muitas empresas adotassem a estratégia e até mesmo cursos foram criados sobre o assunto. Porém, uma coisa muito importante foi ignorada: o modelo era específico da Spotify. Ele se aplicava para a Spotify, naquele momento, com aquelas pessoas que estavam la, nos projetos que estavam em andamento. O contexto foi esquecido. E o mais engraçado é que não muito tempo depois, pessoas da própria Spotify disseram que eles nem trabalhavam mais daquela maneira.
Atreva-se a ser monótono
Não utilizar a técnologia da moda, não ser ágil, não usar os procedimentos de ScrumBanXP v42.25 não faz de você um perdedor. Quando falamos de empresa, falamos de dinheiro, e ser conservador quando o assunto é dinheiro faz bem. Ser conservador (sem falar de politica, ok?!), em essencia, não é não querer mudar a qualquer custo. Ser resistente a mudança é apenas não mudar sem um bom motivo.
Considere os livros e materias de estudo que temos em TI. Quantos livros novos temos a cada mês, ano, etc. E mesmo assim, quais são os livros mais indicados pelos profissionais que adminiramos? Em sua grande maioria, os que passaram pelo teste do tempo: Fred Books, Uncle Bob, Martin Fowler, Kent Beck, Andrew Hunt, David Thomas, etc. Não estudamos padrões de projetos até hoje por capricho. Esse tipo de conteúdo é o que forma a fundação da nossa área.
Tenha um bom motivo quando quiser mudar, lembre-se do contexto, entenda o porque aquilo foi criado, julgue se o que funciona pra X realmente funciona pra você. Grande parte dos nossos projetos tem como objetivo longevidade. Não fazemos um projeto pra jogar fora daqui a 6 meses. Utilizar uma tecnologia estável e consolidada é sempre uma boa aposta. A facilidade de se encontrar informações é maior, a quantidade de desenvolvedores que o conhecem é grande, e isso torna o processo como um todo mais facil.
Um grande benefício de utilizar uma dessas tecnologias, e muito ignorada, é o fato de conhecermos muito bem, também, a parte ruim. Muita gente, ja passou, antes de você, pelos problemas que possívelmente você passará utilizando e é bem provavel que uma solução já esteja pronta.
Conclusão
O título era uma provocação. Não vim para discutir o valor de ninguem. Porém, a ideia central ainda é válida:
- Não otimize antes da hora;
- Julgue o contexto e os motivos de algo existir (ex.: não utilize OKR só porque o google utiliza);
- Considere a facilidade de se manter o sistema após a criação;
- Na dúvida, prefira algo consolidado (PHP e mySQL ainda é a stack muito viável);
