Macetando a Complexidade

[@ojuliomiguel]

Por isso que desenvolver é uma arte!! Bom vídeo!

[@djongaGod]

Mt bom! O que já peguei de código conceitualmente bonito mas uma tristeza de entender e dar manutenção não tá escrito rs. Dá pra fazer código legível, robusto e sem tranqueira desnecessária.

[@matheusnogueira7219]

Bom cafezinho, como sempre. Já viu o trabalho do Eric Normand? Ele escreveu um livro (Grokking simplicity) e está escrevendo outro (Runnable Specifications) onde ele fala sobre modelagem de dominio via código, justamente para lidar com a complexidade de software. Gosto do que ele escreve justamente pq ele evita caminhos "prontos" (clean arch, ddd, etc) e tenta falar sobre como encarar o domínio do problema e traduzir isso para código que faça sentido

[@victor.osorio]

Não conhecia!!! Vou ficar de olho. Será que vai rolar tradução desse Grokking Simplicity? Tá um absurdo na Amazon.

[@victor.osorio]

Ah, obrigado pela dica!!! As formulas prontas são um real problema, porque empobrecem a discussão. DDD e Design Patterns são temas que também deveriam fugir de formulas prontas, mas o que acontece é que muitos não entendem a discussão e acabam criando um espantalho para discutir formulas prontas. Por exemplo, os primeiros 3 capítulos de DDD é sobre não ficar em formulas prontas e o resto é sobre os padrões de DDD, aí pessoal não gosta desses 3 capítulos.

[@matheusnogueira7219]

@@victor.osorio na ultima edição da newsletter dele, ele incluiu um cupom, o valor deve ficar razoavél no site da editora (manning, o cupom é TSSIMPLICITY). mas realmente uma edição em ptbr sendo vendida em real ajudaria bastante

[@RaphaelSousa-or1dl]

Venho vendo seus vídeos mais focados em design de código e você sempre cita que devs mais juniores ou que criam código com maior complexidade carecem de conseguir criar abstrações. Confesso que não está tão claro para mim isso, por exemplo eu não consigo pegar um pedaço de código considerado complexo e extrair abstrações facilmente, como posso melhorar nisso? Ao mesmo tempo já vi algumas discussões dizendo que absatrações mal feitas trazem muito mais problemas que códigos repetidos por ex, qual sua visão a respeito disso?

[@victor.osorio]

Temos que fazer perguntas pro código. Listar responsabilidades e extrair responsabilidades. Uma classe tem que ter uma responsabilidade, uma interface e você deve ser capaz de pedir coisas pra ela. Por exemplo, se você tem uma classe que faz o buffer de um dado e depois processa, porque não criar uma classe buffer? Muitas vezes eu vejo as pessoas colocando todas as responsabilidades na classe pai, o buffer seria uma abstração, muito da lógica pode ser encapsulada.

[@RaphaelJoer]

Muito bom o papo! Semana passada estava lendo sobre a Teoria da Complexidade.

[@victor.osorio]

Fiquei curioso. O que você estava lendo? Era algum post ou livro?

[@RaphaelJoer]

Esse artigo aqui do Edgar Morin: globaleducation767229770.wordpress.com/2021/04/22/para-uma-reforma-do-pensamento-de-edgar-morin/

[@Gabriel-zr4kz]

Me ajude em uma coisa Bom, vou dar um pessimo exemplo: Uma route, controller e uma entity. Meu service pode fazer x coisa, no db, ou analisar aquela complexidade. Complexidade de algol pesa no banco . E saber mediar isso pra mim é faz bastante sentido. Basicamente a gente joga pro banco tudo?

[@victor.osorio]

Cara, eu não entendi bem teu problema. Mas a dica que eu te daria é perguntar qual é a cardinalidade do problema envolvido. Por exemplo, se você tem a opção de trabalhar tudo em memória na sua linguagem as vantagens são que você terá uma boa manutenibilidade do seu software. Todos vão entender facilmente o que está sendo feito. MAS ler e depois escrever no banco pode trazer inconsistência se for um software de alta concorrência. Você sempre tem a opção de fazer tudo no banco diretamente, escrever uma query mais complexa. Eu prefiro essa opção por evitar leitura e envio de dados desnecessário. Essa opção também ajuda a manter a consistência, já que tudo é feito atomicamente. A única desvantagem é que uma query é mais complexa de se ler e de se testar.