Não se preocupe, não parece que está divulgando o curso, na verdade nem sei que curso está falando.
O vídeo é muito bom, só não espere ele ser popular.
Eu construí minha carreira em torno da performance. Mas sempre defendo código legíveis antes de mais nada. Nem sempre ter performance faz o código fica ilegível, e o vídeo passa um pouco isso. Há uma crença que só pode fazer código rápido se ele ficar incompreensível, quando tem casos que é o oposto, o legível é o mais rápido.
Ele mostra muito bem que em alguns casos pode deixar de lado algumas regras que não vão prejudicar a legibilidade tanto assim e ter ganhos absurdos.
O próprio Clean Code tem uma passagem que diz para não seguir regras, nem as do livro, para entender o que está fazendo, fazer escolhas com consciência. Ela é frequentemente ignorada e as outras são seguidas em qualquer contexto.
Tenho uma palestra que fala sobre uma frase do Donald Knuth que tiraram do contexto como começarem justificar que performance não importa, Quase todo mundo já foi submetida a ela, mas o contexto todo era para mostrar que a performance deveria ser muito trabalhava, só que em 3% do código e não todo ele, como acabou sendo divulgado. Ele deve ter a mesma sensação de quem inventou a capacidade nuclear para inventarem uma bomba.
O resultado são aplicações lentas e ineficientes. Enquanto eu não for acionista de quem faz isso está tudo bem. Se isso transparecer para o usuário, e em muitos casos transparece, enquanto eu não for usuário desse aplicativo, está tudo bem.
Obviamente que todo engenheiro com boa qualificação saberá fazer escolhas adequadas para a necessidade em cada contexto. E precisa ser assim.
Vou dar um exemplo que gosto muito e conheço de perto. O Stack Overflow pode rodar com apenas 1 servidor, mesmo sendo um dos 50 sites mais acessados do mundo (varia dependendo da época). Outros sites absurdamente menores precisam de centenas ou milhares. E tem um SEO pior por responder lentamente. É aí onde precisa questionar se a decisão está certa.
Em muitos casos o código é lento e não é legível, até porque só está seguindo regras, não está pensando sobre ele.
O próprio SO já errou. Essa coisa de cache, de arquitetura sofisticada e outras parafernálias que podem ajudar ficar mais rápido, são complexidades e que podem também piorar a eficiência e desempenho. Ele cacheavam, tudo, hoje bem poucos coisas, porque viram na prática que cache não é tão útil assim, em alguns lugares. Não pode adotá-lo como regra, precisa estudar, experimentar, e usar onde faz efeito real.
Não vou dizer que é ruim, mas eu não gosto muito de forçar performance em linguagens de script, a não ser em desperdícios óbvios, simples e nem deveriam existir. Se precisa de performance, um dos ganhos mais fáceis é usar uma tecnologia que já entregue isso.
Até porque não há comprovação que essas linguagens mais "lentas" são claramente mais produtivas. Elas podem até diminuir o tempo de entrega inicial, mas também piora o custo de manutenção futuro, a não ser que se aplique técnicas que baixa a produtividade inicial, então no empate, ainda ficará com algo mais lento, e só tão robusto se tiver esforço adicional.
Desenvolver softwares de qualidade, não é fácil, é trabalhoso e requer muita experiência qualitativa. Todos esses conteúdos ajudam ir entendendo cada vez mais, e não pode ser usado sozinho, é tudo parte de uma reflexão maior. Precisa ter um contraponto.
Obrigado por compartilhar algo tão interessante. É preciso manter a mente aberta para tudo, só assim podemos nos desenvolver bem.
Farei algo que muitos pedem para aprender programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).
