Não otimize o desempenho sem necessidade 😂 Acabei de ver um comentário: > Uma vez que você escale, até mesmo os bugs que você escreveu terão usuários. Meu primeiro emprego após a faculdade foi em uma empresa, e ao entrar, houve um grande seminário de treinamento para novos funcionários. Um dia, eles nos contaram uma história: era meados da década de 90, e a equipe técnica otimizou o tempo de carregamento do software de 5 minutos para 30 segundos. Como resultado, o feedback negativo dos clientes explodiu instantaneamente. Essa otimização do tempo de carregamento destruiu a cultura empresarial daquela empresa. Antes da otimização, todos chegavam ao escritório, ligavam os computadores e aproveitavam aqueles 5 minutos de carregamento para conversar, tomar café e começar o dia de forma descontraída. E agora, antes mesmo de se levantarem da mesa, o software já estava pronto, pressionando-os a trabalhar! A moral dessa história — e a citação acima — não é para você não melhorar as coisas. Pelo contrário, é um lembrete: o software que você constrói não existe apenas no PRD (Documento de Requisitos do Produto) ou no conjunto de testes. É um sistema que interage com as pessoas no mundo real. As pessoas desenvolverão hábitos em torno dele, encontrarão soluções alternativas (Workarounds) e até dependerão de certos bugs para cenários de uso reais. Isso é crucial para você como engenheiro de software: você deve entender o verdadeiro propósito do software e como ele é usado no mundo real. Seu trabalho não é apenas completar uma pilha de tickets dados pelo gerente de produto; seu trabalho é construir software que resolva os problemas dos usuários. Link: