这是 Robert "Uncle Bob" Martin 与 John Ousterhout 于 2024 年 9 月至 2025 年 2 月期间的一系列讨论结果，主要围绕软件设计的三个方面展开：

• 方法长度（Method Length）：

  • 分歧点：John 认为《Clean Code》中关于方法长度的建议过于极端，过小的方法会导致接口变浅和代码纠缠，而 Bob 虽推荐短函数，但不认同有任意数字限制，其分解代码的策略是方法应只做“一件事”，不过 John 认为“一件事”的规则易被滥用且缺乏防护措施。以PrimeGenerator类为例，John 指出其中的方法分解过度，导致代码难以理解，如isNotMultipleOfAnyPreviousPrimeFactor方法与其他方法纠缠，信息分散，增加了读者的认知负担；而 Bob 则认为分解方法有价值，即使可能存在一些问题，也可随时内联。
  • 总结：双方同意模块化设计是好事，都避免代码纠缠，但在分解的程度上存在分歧，John 认为 Bob 的方法会使代码更难理解，而 Bob 认为适当的分解能暴露算法工作方式。

• 注释（Comments）：

  • 分歧点：John 认为《Clean Code》对注释的态度消极，导致代码文档不足，增加软件开发成本，而 Bob 虽承认注释有必要，但反对随意的注释，认为很多注释是不必要的甚至是有害的，如容易误导读者、增加认知负担等。以PrimeGenerator类为例，John 指出该类代码没有注释，难以理解，而 Bob 认为在某些情况下添加大量注释会分散重点，其在相关章节的示例中对注释的使用更为恰当。对于方法名和注释的关系，John 主张用短名称加描述性注释，而 Bob 喜欢用长的方法名来替代注释。
  • 总结：双方对注释的总体看法不同，John 认为注释在系统设计中不可或缺，而 Bob 认为大多数注释实践是无益的，双方在注释的必要性、价值、使用方式等方面存在较大分歧。

• 测试驱动开发（Test-Driven Development）：

  • 分歧点：John 不喜欢测试驱动开发（TDD），认为其强制开发者以过小的开发单元工作，不利于设计思考，会导致先写出坏代码，且对重构缺乏足够指导，容易使开发者陷入战术性编程，忽视整体设计；Bob 则认为 TDD 有很多优点，如减少调试需求、提供低层次文档、促进解耦和支持无畏重构等，且 TDD 并不妨碍设计思考，只是将设计融入到开发过程中。以计算保龄球分数的视频为例，John 指出 TDD 在视频中未提及设计，只是事后清理 mess，而 Bob 认为设计是推测性的，可能会因代码而改变。
  • 总结：双方都认为单元测试重要，也都承认 TDD 可以生产出好的系统，但在 TDD 对设计的影响、是否鼓励设计、与其他开发方法的比较等方面存在分歧，John 认为捆绑式方法更优，而 Bob 认为 TDD 和捆绑式方法效果相似，且 TDD 可能更有生产力。

总体而言，双方在软件设计的多个方面存在分歧，但都强调了设计的重要性，并认为开发者应保持纪律和思考，以生产出高质量的代码。Bob 表示已将 John 的一些观点纳入《Clean Code》第二版。