……让我在这里给你一个非理性的例子。我当时在一家大型科技公司工作，作为分解我的项目的一部分，我尝试了代码的另一部分。我的预测准确率在客户数据上翻了一番，并且代码运行得更快，使用的内存也更少。这在客观上是更好的。而且这甚至“免费”实现了，因为这些任务是我原始工作的组成部分，尽管目标并不明确。结果如何？据我所知，这个PR仍然处于开放状态。老板没有推动它，因为他们更关注其他尚未完成但包含更多术语的工作。那项工作仅比我做的准确率稍高一点，但需要100倍的计算量，并且需要10倍的内存。我甚至告诉他们，我的方法也可以用于那项工作，但从未实现。我见过很多类似的情况。有时候人们只是不想让事情变得更好，除非它以一种非常特定的方式变得更好（而且不一定通过性能）。有时候只是因为政治因素。另一方面，我也见过一些非常优秀的团队，那里的体验正好相反。……
源讨论重新审视克努斯的“过早优化”论文原帖 141 条评论 · 导入时统计> 正是这种“让人安于现状”的情况，当我大多数人引用那句话时，我都在反对。太多人试图关闭关于改进代码（不仅仅是性能）的对话，他们不惜使用诉诸权威来转移话题。 你的评论看起来像是一种稻草人论证。没有人反对“改进代码”。你在说什么？看起来你是在曲解任何与你想法相左的评论，不管这些评论多么错误，都把你的想法包装成显而易见的改进，只能被那些反对好代码而支持坏代码的人批评。 这是老套的软件开发者的陈词滥调的重演：“我不会错，而周围的人都做不好”。 讽刺的是，你就是Knuth的名言所要保护的软件免受的那类人：那些未能理解“优化”主张的人…
完整原文把你的经验，加入这段讨论。
> 这其实是一个常见的现象。但说实话，通常不会用完全相同的措辞出现。通常会说“让我们把时间花在其他不重要的事情上，但因为是新的所以变得重要”。这是真的，有时候你需要优先处理，但有一个明显的偏见，一旦某样东西“能用”（不管有多差），就很少有动力让它不再那么差。 没错。“它技术上能运行，所以不需要关注”已经成为行业常态。有一种巨大的偏见，倾向于添加更多功能，而不是让旧的功能变得更好。
完整原文在这个项目中，我成为了批量处理的专家。整个项目是一个读取密集型的工作流，应该在写入时就做出所有决定，但当我接手时，它已经深入到无法拔出的地步。而我说服的每个人最终都选择离开，而不是留下帮助修复它。 但有一些部分我们可以在构建或部署时解决，我能够修复其中的许多问题。 有个人被指派了一个我变成史诗级的项目：在部署时构建备用错误页面并将其推送到 CDN。我告诉他不要按照他原来的方式构建，而是复制我之前正在工作的那个。我忙于其他事情，他离开了，后来我们发现当客户更改联系方式时，他们没有更新，几个月后才发现我们仍然有旧的信息。 构建触发器没有下游依赖关系，也没有发送警报…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。