Distância entre Tomada de Decisão e Origem dos Dados: Impacto no Design de Código

  Рет қаралды 830

Dev Eficiente

Dev Eficiente

Күн бұрын

Пікірлер: 10
@leandromartins457
@leandromartins457 5 ай бұрын
Parabéns Alberto, achei que faz muito sentido. Já perdi as contas de quantas vezes, sob a desculpa de reutilização de código eu já fiz um componente que deveria tomar todas as decisões do fluxo. No início, de forma ingênua o componente parece simples, porém, com o crescimento das necessidades e especificidades acaba que toda vez ele deve sofrer uma refatoração para corrigir pontos que divergem entre os usos. Para mim o estudo de diminuição de carga cognitiva faz mais sentido a cada dia.
@DevEficiente
@DevEficiente 5 ай бұрын
Opaaaa, legal demais que curtiu!
@danieljazz1
@danieljazz1 5 ай бұрын
Muito boa essa reflexão. É algo que faz muito sentido mesmo! Porque a tendência é sempre querer mexer no que já existe e às vezes dá mais trabalho do que se tivesse simplesmente criado um novo endpoint.
@DevEficiente
@DevEficiente 5 ай бұрын
Opa, enxergo de maneira parecida. Não é trivial encontrar o nível certo de generalização.
@danielvicentefagundes6774
@danielvicentefagundes6774 5 ай бұрын
Interessante
@DevEficiente
@DevEficiente 5 ай бұрын
hehehehe :).
@alinecarvalho373
@alinecarvalho373 5 ай бұрын
Bastante interessante essa reflexao Alberto. Acho que no exemplo dado, faz mais sentido mesmo apenas 1 endpoint mais coeso para cada forma de pagamento. Agora se o me contexto me exigisse multiplas origens de pagamento alem do hotmart do exemplo, eu tenderia para uma implementacao similar a segunda opcao, ja que nesse caso (pelo menos pra mim), seria ruim ter varias implementacoes especificas em funcao de cada checkout. Outra coisa que fiquei pensando e que, na segunda opcao, alem das decisoes de fluxo, o codigo tambem teria que ter o cuidado de tratar o pagamento da forma correta ja que o client pode enviar novo pagamento request com multiplas informacoes de pagamento (cartao e pix por exemplo), sendo que o intuito seria efetuar apenas 1 pagamento.
@DevEficiente
@DevEficiente 5 ай бұрын
Oi Aline, massa que curtiu! Você fala de ter endpoints por origem para lidar com os tipos de pagamentos daquela origem?
@RaphaelSousa-or1dl
@RaphaelSousa-or1dl 5 ай бұрын
To implementando exatamente a segunda implementação que você propôs, temos um fluxo comum para todos os pagamentos, mas as implementações das interfaces dos processadores estão em microserviços. Foi uma ideia dificil visto o acoplamento e dificuldade em possíveis debugs, mas teremos fluxos complexos nos processadores e decidimos mante-los separados. Ainda to no inicio dessa implementação mas to me preparando pros possíveis problemas que surgirão devido a essa decisão
@DevEficiente
@DevEficiente 5 ай бұрын
Opaaa, valeu demais por compartilhar!
When u fight over the armrest
00:41
Adam W
Рет қаралды 22 МЛН
Smart Sigma Kid #funny #sigma
00:14
CRAZY GREAPA
Рет қаралды 106 МЛН
SOLID (O básico para você programar melhor) // Dicionário do Programador
16:22
O que o problema com a CrowdStrike nos ensina sobre aprendizagem
17:34
Lógica no controller, será que pode produção?
12:03
Dev Eficiente
Рет қаралды 1,3 М.
The Better Way to Manage React State
7:38
Josh tried coding
Рет қаралды 32 М.
The M4 Mac Mini is Incredible!
11:45
Marques Brownlee
Рет қаралды 4 МЛН
🚀  TDD, Where Did It All Go Wrong (Ian Cooper)
1:03:55
DevTernity Conference
Рет қаралды 565 М.
Aprendendo Clojure Do Zero #1: Como se orientar no começo de tudo
27:03
Seis Passos para Triturar Qualquer Requisito
23:55
Dev Eficiente
Рет қаралды 778
When u fight over the armrest
00:41
Adam W
Рет қаралды 22 МЛН