283 - Clean Code DETONA a PERFORMANCE?!?! 😱😱😱 | theWiseDev Controversy

[@figloalds]

Nas linguagens gerenciadas mais usadas hoje tipo C#, Java, Python, Javascript, etc, o maior impacto de performance é o GC e cada uma dessas linguagens tem um mecanismo pra mitigar esse impacto, porém o problema é sempre causado por alocação e "new AlgumaCoisa()" é alocação, eu ultimamente tenho evitado muito criar novas classes só por criar, cada vez mais tenho programado "multiparadigma" e menos "OOP", tem conceitos de OOP que causa muito problema, não só de performance, mas também de manutenibilidade do código, por isso eu tenho aplicado cada vez mais o lado bom de funcional e deixado o lado ruim de OOP de lado

[@otaviolemos]

Eu também!

[@igorlmfs]

A melhor abordagem é a do Martin Fowler, refatore para o código ficar mais legível, em caso de perda de performance vc tem um código muito mais fácil de mudar para que ele possa ganhar performance.

[@artu_almeida]

(3:12) concordo que não é um benchmark cientifico e acurado, mas vale lembrar que "aquele exemplo em c++, naquele código especifico" foi escrito pelo uncle bob, é um código que o proprio uncle bob utiliza para fazer clean code, entao não é como se o Muratori tivesse criado propositalmente um código que ficasse mais lento depois de limpo, ele pegou o próprio código usado pelo uncle bob, para defender o ponto dele, acho q o objetivo era esse, e nao fazer um benchmark cientifico e tals, e ele conseguiu hehehe sendo coincidencia ou não, os códigos de exemplo q o proprio uncle bob utiliza, são mais lentos depois de limpos 🤷🏻‍♂ (4:16 & 8:00) Boa!! falou tudo, dependendo do lugar do sistema, vale a pena fazer um switch, e dependendo, vale a pena usar chamadas polimorficas, tudo é um trade-off... design patterns tem seu uso, sabemos quando usar e quando nao usar... e com clean code nao seria diferente...

[@otaviolemos]

Não sei se o código foi escrito pelo Uncle Bob. É um exemplo clássico didático de polimorfismo / POO usado em vários lugares. Acho engraçado o Muratori dizer “eles” como se houvessem dois partidos. Isso é meio prejudicial para a discussão, a meu ver.

[@artu_almeida]

@@otaviolemos no video dele, ele explica, veja no minuto 2:46

[@otaviolemos]

@@artu_almeida eu vi, Arthur, ele não diz que pegou do Uncle Bob, ele diz que é um exemplo comum de Clean Code (pode ser que esteja no livro mas ele não fala explicitamente; diz que pegou “deles”). Ouça de novo.

[@lucassouzati]

Excelentes pontuações. No final é sempre uma questão de valor. O que impactaria mais o projeto ou empresa: alguns millisegundos a mais na execução do codigo ou codigo "sujo" que vai impactar em mais horas de trabalho necessárias para manutenção e atualização?

[@marlonscastro]

Comentário excelente.. 👏🏻👏🏻. Pra maioria das aplicações alguns ms a mais não alteraria em nada a experiência do usuário.

[@AniltonNeto]

Vs code é rápido quando não tem plug-ins 😅

[@otaviolemos]

Não sei, o meu está lotado e ainda roda bem (talvez seja porque tenho um iMac poderoso 😅).

[@antonioabrantes4262]

Primeira opinião lucida que vi sobre estas duas polemicas do momento! Parabêns!

[@otaviolemos]

Valeu, Antonio!

[@Oculterous]

Eu acho que náo depende da arquitetura e sim como a Linguagem usada compila ou otimiza o código, Eu estou fazendo uma monolito modular, no momento que precisar separar ele [e bem simples

[@kellenxavier3420]

Baita opião mesmo e bem lúcida, um comentário aqui no tempo 8:06 "uma alma por uma alma" 😂

[@noriller]

Acho que essa escovação de bits só vale a pena quando o custo de manter um código menos legível só que muito mais eficiente fosse menor do que o que é gasto entre rodar o código e o que ganha os desenvolvedores. Não lembro onde vi agora, mas colocaram na conta o custo/hr do desenvolvedor na hora de usar uma ferramenta (tipo colocar as coisas no serveless) junto com o custo da ferramenta, daí uma ferramenta que custa, digamos 1000 dinheiros pode parecer caro, mas pode salvar em produtividade 2000 dinheiros, então por mais caro que seja, ela vale a pena. Um código menos eficiente pode gerar um custo maior? Sim. Se escovar bits e ir mais baixo nível, pode fazer algo mais rápido (mas provavelmente mais difícil de manter)? Sim, mas acho que são poucas as empresas e ainda menos os caso de usos onde o custo desse trade-off vale a pena.

[@otaviolemos]

Também acho. Parece-me que há muito mais perda de tempo - custo - para entender e lidar com código mal escrito.

[@roadtripperchannel]

Cada caso é único. Por exemplo, se tem um jogo é ele está rodando abaixo de 30 FPS que é visível ao olho humano, e se está usando Clean architecture, nesse cenário é crítico, então nesse caso vale a pena analisar e talvez mudar a arquitetura. Agora digamos que o jogo esteja a 50 FPS, usando a mesma arquitetura e não esteja impactando a performance, não tem porque mudar. É tudo questão de análise. Mas para a maioria das aplicações, essa discussão é mais para chamar atenção, se você não trabalhar em uma big tech que necessita de tanta performance, não precisa ficar louco com isso. E parabéns pelos conteúdos do canal, percebe se a qualidade e que houve pesquisa antes.

[@otaviolemos]

Boa, valeu!

[@lucasxciv]

Ótimo vídeo, professor. Lembrei do livro de refatoração do Martin Fowler que tem um tópico interessante sobre isso chamado "Refactoring and Performance". Onde ele comenta o seguinte: _"A common concern with refactoring is the effect it has on the performance of a program. To make the software easier to understand, you often make changes that will cause the program to run more slowly. This is an important issue. I'm not one of the school of thought that ignores performance in favor of design purity or in hopes of faster hardware. Software has been rejected for being too slow, and faster machines merely move the goalposts. Refactoring certainly will make software go more slowly, but it also makes the software more amenable to performance tuning. The secret to fast software, in all but hard real-time contexts, is to write tunable software first and then to tune it for sufficient speed."_ _"I've found that refactoring helps me write fast software. It slows the software in the short term while I'm refactoring, but it makes the software easier to tune during optimization. I end up well ahead."_ ― Martin Fowler, Refactoring: Improving the Design of Existing Code

[@otaviolemos]

Excelente ponto!

[@ungaratto93]

Professor, O exemplo da chamada polimorfica vs switch case, se ele for transposto para um cenario mais complexo, onde que os tipos possam ser acrescidos ao longo do tempo, por exemplo, n formas de calcular a precificacao de imoveis. Nesse contexto, a passagem de objeto dessas classes concretas que sigam a interface, se torna melhor A estrategia de calculo sai do switch e vai para a classe detentora do calculo em si. Entrentanto a medida que a criacao de objetos ocorre, a memoria vai sendo populada com eles.... Sobre microservicos vs monolitos, eu ja vi em alguns lugares, que a arquitetura do software poderia refletir o organograma da organizacao, de fato onde vemos que microservicos sao bem vindos, e em grandes equipes atuantes e solucoes de software distribuidas.

[@artu_almeida]

Otavio, se a Amazon tivesse seguido o que o Martin Fowler diz naquele artigo "MonolithFirst", não precisariam fazer essa migração kkkkk

[@otaviolemos]

Exato!

[@jaksonxavier]

- "Todo fanatismo é prejudicial, pois cega a razão e impede a busca pela verdade." Se "apaixonar" por um conceito seja ele qual for só vai trazer prejuisos no desenvolvimento. Como bem dito no video o ideal é conhecer os dois lados e saber quando deve aplica-lo. No entanto deveria ser de conhecimento comum que um código claro e testado seja menos complexo de ser perfomado.

[@alexdiasdeoliveira3218]

Boa, professor! Sem partidarismo e muito lúcido. Uma coisa bem legal e que eu não tinha pensado sobre essa discussão toda é o que senhor disse sobre a insignificância acadêmica dos testes do Muratory. Muito efeito pra treta de Internet, mas zero valor pra "sentenciar o Clean Code à morte". Além disso, quando ele critica o polimorfismo, ela critica mais a Programação Orientação a Objetos do que o Clean Code mesmo. 😀

[@TecnocraciaLTDA]

Esse vídeo é uma grande e excelente reflexão sobre o assunto.

[@otaviolemos]

Muito obrigado, Lucas!

[@thiagofelipe4998]

Um disclaimer importante sobre clean code é que ele não deve ser entendido de forma canônica, o uncle bob no seu blog já chegou a comentar em uma postagem algumas das criticas feitas às ideias defendidas no seu livro e no geral conseguiu exprimir essa ideia

[@mrblackcarneiro]

Sim, clean code detona a performance. Nem precisa ser gênio pra saber disso. Quanto mais camadas tem a aplicação, maior o tempo de processamento. Não tem como refutar isso. No entanto, uma aplicação que facilita a manutenção, torna mais fácil o trabalho de tunning.

[@taveirinha1337]

Perfeito! É como o Akita fala, toda otimização burra é ruim. Começar a aplicação visando performance extrema é burrice, exceto em contextos que exigem isso, como sistemas de tempo real, fora que código limpo permite refatoração de pontos chaves pra desempenho

[@ojuliomiguel]

Em resumo: só fizeram alarde! Clean Code segue forte!

[@otaviolemos]

Certamente! 😅