Balança da arquitetura de software

Fotografia de capa por Ries Bosch, tirado por uma Nikon D5600

Galera umas das lições mais importantes que tive na minha carreira é saber nivelar complexidade instrumental de complexidade inerente.

Complexidade instrumental = Linguagens/bibliotecas/frameworks que você coloca no projeto

Complexidade inerente = É a complexidade do projeto em si

Ex:

Complexidade instrumental = Node.js, Typescript, ReactQuery, Zod..

Complexidade inerente = Aplicação de apostas online, sistema de controle de estoque

Quando criamos um produto precisamos nivelar essas duas, caso contrário o que acontece é

Complexidade instrumental > inerente = over engineering

Complexidade inerente > instrumental = reinventar a roda

As vezes colocar ReactQuery no projeto vai mais atrapalhar do que ajudar.

Tá, mas como acho o ponto de equilíbrio?

Aí entra um movimento chamado boringtechnology.club, que funciona basicamente assim:

No lado esquerdo temos problemas do nosso negócio e do lado direito temos as tecnologias que pode ou não nos ajudar a resolver os nossos problemas.

O objetivo é tentar conectar os círculos para resolver o problema (escolha da tech).

A cada escolha, vem também um benefício e um custo de manutenção, ou seja, se você for resolver outro problema e precisar de outra tecnologia, a equipe paga pelo custo de manutenção.

Se você tem 1 benefício para 1 custo, logo eles se anulam, agora se você tem mais de um benefício para um mesmo custo, a escolha da tecnologia se paga.

Nesse caso, 1 tecnologia resolve 2 problemas com o mesmo custo 🔥