Como encaro tecnologia e arquiteturas de software

Eu já estou trabalhando com tecnologia tem um tempo. Nos meus 2 ultimos anos tenho sido responsavel por tecnologia em algumas startups e também como Principal Engineer em um big tech no time de Design System. Vou tentar colocar de forma ssimples alguns principios que me guiam nas decisões.

Primeiro é tirar a paixão e visões como um sendo melhor do que o outro, ou de se sentir ultrapassado por estar trabalhando com algo diferente da palestra ou da tecnologia mais comentada por devs aqui no Twitter. (Twitter não é o mundo real)

Segundo, pensar sobre o problema. Qual problema ela resolve? Nem sempre o mais popular representa a melhor resolução de problemas. Citando um exemplo, node com SSR geralmente é péssimo para os recursos do servidores e você talvez até gaste mais por isso. Como estamos vivendo em um periodo de abundância de recursos, esse erro não está sendo percebido, mas pode vir cobrar em algum momento.

Nós criamos ferramentas, usando outras ferramentas para resolver problemas. Algumas ferramentas, precisam resolver problemas de escala do usuário, perfomance ou custos, ou até mesmo a escala do time.

Antecipar alguns problemas óbvios, mas também não resolver o problema que nem existe ainda é sempre importante.

Por exemplo porque correr o risco de escrever minha própria ferramenta de documentação de design system se temos o storybook? Porque escolher microserviços se ainda nem sei quais são meus números de usuários?

Falando sobre time, um outro exemplo seria, você consegue manter mais consistência e escala com um time escrevendo em Angular com TS do que React.
React tem uma natureza que facilmente pode virar um gargalo no desenvolvimento, sem um controle rígido e opinativo dos devs mais experientes. Um é melhor do que o outro por isso? Não! São problemas diferentes abordagens diferentes.

No Fiança Rápida por exemplo escolhi svelte, acredito que a abordagem de reduzir consumo de processamento da biblioteca será melhor do que ser formos para React, dado a característica do nosso usuário. E isso também ajuda no processo de seleção, para entender a flexibilidade de quem estiver conosco. Mesmo que podemos mudar rápidamente de framework se algum problema surgir após nossas escolhas.

Sugestões de arquitetura, precisam ser avaliadas de acordo com que os problemas surgem. Por isso um senior/tech lead/principal/CTO precisa olhar para o mercado e entender bem o que estão resolvendo antes de propor arquitetura.

Produtos em startups, precisam ser de fácil construção e rápido deploy em produção, diferente de um produto em uma big tech, onde você precisa gerar entregas próxima da perfeição e com excelente planejamento, já que se tornará algo quase infraestrutural.

Tem partes de uma startup que também precisa ser avaliado como estrutural, por isso um cuidado extra com o back-end é mais necessário do que com o front. Ambos são importantes e precisam de atenção e cuidado.

Um arquitetura monolitica pode ser muito util no inicio e até que surjam problemas especificos, que atrasem a entrega dos times, quebrar ela pode ser problemático.

Terceiro, colete dados. Você não sabe se tem o problema se não estiver dados para dizer que tem um problema. Aqui entra todos os tipos de dados, por exemplo, o time está demorando para entregar, como isso é medido? É seu sentimento ou tem dados mostrando isso? E é aqui q caímos no q eu chamo de scrum a brasileira e vira essa caos de cobranças por entregas q não aconteceram, mesmo fazendo a metodologia.

"Aqui somos ageis e usamos scrum", mas retro, planning com pontuação para entender a complexidade e visibilidade dos problemas enfretados, não existe ou quando existem são ferramentas de cobrança ao invés de medição do cenário.

Métricas de crash, métricas de acesso, métricas de consumo do servidor são essenciais para saber quais problemas você vai resolver. Se não tem métrica você não tem problema e sem problema para resolver você não tem  emprego. Código é só o meio que resolvemos problemas.

Componentes

Desde de que me deparei com programação funcional e também filosofia linux, vi um conceito que acho que são bem correlatos, uma função com o mesmo input gera o mesmo output e fazer uma única coisa e fazer bem.

Software é o empilhamento disso, quanto mais isolado estiverem as funcionalidade se em interferencia, a composição e reuso, vai aumentando a velocidade de resolução dos problemas. Note que estou falando de componentes dentro de uma mesma tecnologia.

Acredito que a quebra de tecnologias dentro de um mesmo produto é somente quando necessário escalar o time ou a tecnologia proposta não resolve o problema. E quando necessário, precisa ser algo do tipo inputs claros e que geram o mesmo output no produto e são subprodutos de um produto principal.

Inclusive foi assim que microserviços surgiu e o React também. React ele foi feito para existir como widgets de aplicações não como a aplicação completa, tanto que vemos o esforço necessário de libs auxiliares para usar ele como aplicação completa.

Alguns produtos já nascem com esses subprodutos de forma bem clara, mas só separe se realmente for válido e necessário. Evite a otimização prematura, mas não vá para o extremo de que não precisa de otimização alguma.