Simplifique!!!

---

Por que complicar?

Nós que trabalhamos com tecnologia sabemos bem, que a cada dia que passa problemas mais e mais complexos aparecem no nosso dia a dia.

Você já se sentiu como um Imã? Como se sua força de atração a problemas complexos fosse ficando cada vez mais implacável?

Sim, isso é normal na nossa carreira, conforme nossas competências aumentam, maiores os problemas que nos encontram. Mas cuidado para não se apaixonar por eles, ou até mesmo aumenta-los.

Um dia desses estava participando da discussão sobre o desenho de arquitetura de referência de um sistema, quando me deparei com uma situação inusitada. Estávamos desenhando algo extremamente complexo, para tratar algo ridiculamente simples.

Quando consegui enxergar essa situação, comecei a mudar nossa forma de pensar no problema, e chegamos a uma solução extremamente mais simples.

Como sempre, quando me deparo com um ponto de melhoria, eu busco refletir depois sobre ele, e em como isso pode me ajudar no futuro, como posso quebrar minha linha de raciocínio para ser mais eficiente.

Parando para pensar, consegui elencar algumas vezes nas quais me vi seguindo por caminhos complexos para resolver problemas simples, mas por que?

Acredito que conforme vamos ganhando experiencia e desenhando sistemas robustos e inovadores, começamos a buscar em cada oportunidade um desafio de fazer algo especial. Mas precisamos?

Por muitas vezes conseguimos resolver o problema e buscar valor rápido com soluções simples, sem nos apegar tanto a detalhes, e teorias mirabolantes. Portanto, sempre que possível, SIMPLIFIQUE AO MÁXIMO o sistema que você pretende construir, sistemas mirabolantes trazem complexidades que nem sempre se pagam.

Se pensarmos no que nos é ensinado, vamos buscar sistemas perfeitos, sem falhas e que consigam resolver qualquer situação. Quando na verdade deveríamos buscar sempre o melhor sistema para a situação, ponderando as chances de cada situação e se vale o investimento e a perda em complexidade em criar algo muito rebuscado.

Não é uma equação fácil, mas busque sempre simplificar. E para quem ficou curioso sobre o problema que comentei, vou colocar aqui duas situações principais, mas sem me aprofundar muito:

 1-) Definição de granularidade de microsserviços.

Quando estávamos construindo uma de nossas aplicações optamos em seguir diversas boas práticas de literatura. Saímos de um monolito para uma aplicação extremamente granular.

Nossa ideia era trazer independência para os microsserviços, diminuindo atritos em construções e testes futuros. E principalmente menos chance de impactos gerais para o nosso cliente.

O que conseguimos foi um sistema tão granular, que nosso tempo de troubleshooting, preparo de testes integrados e controle de dados nos tornou lentos.

Voltamos um passo e agrupamos alguns domínios, mudando nossa forma de pensar no nosso negócio, o que nos trouxe maior equilíbrio, e muita eficiência.

2-) Definição de modelos de dados.

De forma mais simples, ao olhar os domínios das informações, definimos cerca de cinco bancos de dados para tratar parte do sistema. Um conceito de domínio dentro de domínio.

Resultado? Nosso dado ficou bem modelado pensando em informação. Mas a operacionalização disso ficou extremamente lenta. Para trabalhar os dados era necessário buscar em cinco tabelas. Hoje são duas, com algumas colunas a mais, e com uma performance extremamente melhor. Esse modelo já se sustenta a pelo menos quatro anos.

Obrigado por ler até o fim, deixe seu comentário, conte sua experiência. Ajude a manter esse canal vivo.

Forte abraço, Natan Pasquarelli Freitas.