Thread by @GubnunBR

🚨PARE DE OVER ENGINEERING 🚨

Leia esse post e reflita. A quantidade de código obfuscado que eu vejo é grande, e em geral quanto menos senior a pessoa, mais obfusca o código, abusando de conceitos tanto OOP, quanto funcional. Esse fio é sobre isso 🧵
#bolhadev cc: @sseraphini

Já entrou numa base de código que a sua sensação é que vc navega, navega e só tem “osso” ali, não tem uma “carninha” onde está o verdadeiro business logic da parada? Vc ta procurando por exemplo quem lê o arquivo, onde ta a lógica que faz aquilo, mas vc só encontra abstracão..

São arquivos e arquivos tentando achar de onde vem, e vc acha a parada láá escondida em algum lugar, essa eh sua “carne”, o resto tooodo que vc navegou era “só osso”, abstração atrás de abstração pra fazer algo simples.

Nao sei se pro dev junior, isso pode parecer uma coisa do tipo: “Nossa, que código complicado, mas é assim que deve ser aplicação profissional né? Muita abstração por que é complexo”. NÃO, oq provavelmente você ta lendo, é um código lixo mesmo.

Já trabalhei em aplicações com milhões de linhas de código, uma engine inteira de um jogo AAA por exemplo, e o código pode ser simples e objetivo. E já vi gente fazendo um app MUITO simples, em uma complexidade CAÓTICA.

Não sei se as pessoas querem mostrar que sao inteligentes, ou sei lá… vou dar um exemplo concreto. Você chega pra pessoa e fala, “opa vai ter um arquivo de input e a gente precisa ler”. Amigo, você vai fazer uma função que lê o arquivo e acabou.

Você nao vai fazer nada “future-proof”, isso nao existe. Você nao vai fazer uma interface IFileReader, que tem um monte de função, que lê um arquivo, que lê uma lista de arquivos, que lê arquivo texto e binário, que comprime e descomprime o arquivo, vc nao vai fazer…

…uma IAdaptorAbstractFileFactoryJavascriptBeans!!! Não para!! Quando começo ler esse tipo de coisa em código, já fico louco. Se você tem UM requisito, você faz AQUELE requisito, se o requisito muda ou se expande, você REFATORA.

Nao tem nada errado em fazer um ou dois copy pastes, se vc ver que vai virar um pattern, aí sim vc bota em uma função, aí sim vc bota numa classe, vc faz um estado. Nao existe essa de fazer código “pronto para o futuro”, vc não sabe o futuro.

A mesma coisa vale pra quem abusa de funcional, vejo muito isso em quem abusa de curry, tipo:

const sum => x=>y=>z=> return x+y+z;

sum(1)(2)(3); //6

Porra amigo! Aí vc me quebra… obvio que nao é simples assim, mas vcs sabem do que to falando…

Ao inves do cara fazer um lambda, seguir uma stream de código funcional que tem lógica.. nao, eh funcao que recebe uma funcao, e retorna uma funcao que retorna uma funcao dentro da funcao, que aí tem um callback que vc tem que passar pra essa funcao… 🤯

O cara quer amarrar a parada em um purismo funcional sem justificativa alguma. Nao tem nada de errado com código simples e empírico.

Frameworks e bibliotecas são outra parada tbm que obfuscam demais, balanceie MUITO o custo/beneficio de introduzir um framework/biblioteca nova no seu código. PRINCIPALMENTE se for um framework “zumbi”

Framework “zumbi” é aquele que se alastra na sua base de código, é dificil mante-lo isolado em um cantinho, ele simplesmente vai impregnar seu código inteiro (alô RxJS)

Ultima coisa é, se você tem um sistema orientado a eventos, TENHA CERTEZA que você tem ferramentas para ter observabilidade desses eventos. Quando algo acontece no código, a primeira coisa que você quer saber é aonde está o originador do evento e por qual processo…

…esse evento passou pra chegar até ali. Sistemas baseados em stack são bem mais fáceis, porque você consegue ver o originador da ação na base da sua callstack.