《“干净”代码，糟糕的性能》（2023）
对“Clean Code”式面向对象设计的批评认为，它对小方法、深层多态层次和隐藏内部实现的强调，会通过对抗 CPU 缓存并增加间接层而导致性能不佳。评论者反驳说，这些模式原本是为了提高可读性和可维护性，真正的瓶颈往往在别处（例如网络 I/O、沉重框架），而不在虚拟分发。更广泛的主题是，诸如 DRY、小函数和接口之类的编码“原则”只有在结合具体领域与约束、经过判断后使用时才有价值，而不应被当作教条机械遵循。
Clean Code 的价值与局限
- 许多人认为这本书对需要结构的早期开发者来说很有用，像是一种搭建脚手架的工具。
- 也有人认为它只教了糟糕或狭隘的实践（仅限“干净的 OOP 代码”），即使对初学者也有害。
- 常见批评是：它鼓励教条式规则（超小函数、多态、排斥注释），并以说教口吻把异议标为“不专业”。
- 有人提到有一个较新的版本，试图修正误解，但其质量被认为并不明确。
性能 vs. 可维护性
- 核心争论在于：“干净”的抽象（尤其是 OO 和多态）往往会损害性能，但可能有助于维护和扩展。
- 一些人认为性能应由测量来驱动：先写简单代码，再优化热点。
- 也有人反驳说，某些风格（大量运行时多态、深层抽象层）会让系统整体变慢，而不只是热点变慢。
OOP、多态与替代方案
- 许多人指出，经典示例使用运行时多态和 vtable，这些众所周知比扁平数据和 switch 更慢，尤其在紧密循环中。
- 有人强调现代编译器会很好地内联小函数；真正的成本主要是动态分发，而不是“干净代码”本身。
- 提到的替代方案包括：和类型加穷举匹配、过程式分发（switch 或表驱动）、静态多态，以及新语言中的零成本抽象。
函数大小与结构
- 对函数长度规则存在强烈分歧。
- 有人喜欢非常小、单一职责的函数，认为更清晰；也有人觉得这种风格过于碎片化，更难理解。
- 只要是“做一件连贯的事”，长但线性的函数也可以接受；人为拆分反而会损害可读性。
原则 vs. 教条
- 一些评论者强调，DRY、SRP 和“clean code”等原则只是带权衡的低层工具，不是普适定律。
- 过度应用会导致松散耦合、碎片化、低内聚和性能问题。
- 共识性的主题是：要用判断力；上下文（领域复杂度、性能需求、团队规模、可扩展性）应当决定设计。
对文章和示例的批评
- 有人认为这篇批评针对的是一个玩具式、并不关注性能的示例，因此有稻草人之嫌。
- 也有人回应说，示例本来就出自书中，它具体展示了所倡导风格如何降低性能，这一点即使原意是教学性的，也仍然成立。
更广泛的生态系统抱怨
- 多条评论认为，在日常应用中，最严重的性能问题往往不是 OO 模式或函数大小/多态本身，而是更重的技术栈（例如 Electron、桌面上的“web 技术”）以及网络延迟。