…我最近‘继承’了一些后端服务，当一名开发人员离开我们公司时。结果发现代码非常糟糕，而且他们根本没有使用任何我们的辅助工具。因为我们到处都使用 Typescript，忽略我们相当有意见而且有点专制的 linter 规则几乎是不可能的，但这位开发人员有权限关闭它，他们确实这样做了，结果自己给自己造成了麻烦。后端服务是用 JavaScript 而不是 Typescript 开发的，由于我们的 linter 和常规的测试流水线都被禁用了，而且这些软件已经经历了近一年的修改，所以非常糟糕。我们说的是循环比较值，这些值可能曾经存在过，但现在只是像 undefined === undefined 这样的糟糕情况。性能也非常糟糕。…
源讨论性能借口被揭穿原帖 125 条评论 · 导入时统计把你的经验，加入这段讨论。
他在文章开头列出的观点基本上是马丁·福勒（以及因此90%的企业工程师）在《重构》中的立场。福勒可能是在回应工程师以（有争议的性能）为借口让代码难以理解的情况，而穆拉托里在这里则是在回应由此产生的过度反应。
完整原文> 我不确定人们是否真的这么说。 在我的职业生涯中，我遇到过一些真正不在意性能的人。对他们来说，代码要么能运行，要么不能。在大家都使用裸机的年代，如果一个开发者提交的更改突然需要10倍的硬件（或让其他团队的服务产生10倍的请求），这会破坏系统，迫使人们采取行动——要么订购更多硬件（需要时间），要么修复软件（通常更快）。如今云服务会自动扩展，这样的更改可能不会被注意到，唯一的变化就是下个月的云账单。
完整原文我不太明白。 > [糟糕的开发者花了一年的薪水来构建一个无法工作的东西] 你提到的重写成本暗示只需要一两周的工作量。为什么这个开发者花了整整一年？ 真的糟糕的开发者确实很糟糕，重复工作非常昂贵。 > 我并没有因为性能差而重写它 > ... 有巨大的性能提升，一旦我完成构建缓存，它会更好。 所以即使有巨大的性能提升，你仍然需要进一步提升性能？听起来即使系统原本写得不错，你也必须重写部分系统。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。