《软件设计的哲学》和《代码整洁之道》的分歧讨论

[Curtion]

《代码整洁之道》应该算一本很经典也很大众的书籍了，我在很多程序员书单上都见过它。

《软件设计的哲学》则是一本更新的书籍，我在看的时候发现这本书有很多独特的观点，例如作者支持大而深的类，作者反对 TDD 等

查资料时，意外发现两本书的作者有相关的讨论，并已经记录下来了:

https://github.com/johnousterhout/aposd-vs-clean-code

感兴趣的可以看看

[craftsmanship]

感谢分享 这两本一直躺在书库里没翻过…

[shilianmlxg]

感谢大佬分享，用 deepl 翻译也能看。

[pkoukk]

从我的哲学观点上，我是绝不可能接受大而深的类

[cppgohan]

两本书都看过, 感觉共性是大部分, 分歧更多是实践细节

油管有两个作者针对分歧的讨论, 函数长度, 代码注释, TDD (看到楼主给的资料里也提到了)
<amp-youtube data-videoid="3Vlk6hCWBw0" layout="responsive" width="480" height="270"></amp-youtube>

A Philosophy of Software Design 这本书比 Clean Code 出来的晚了 10 年

函数长度我更倾向于前者, Clean Code 太理想了, 实践中不可行

注释我倾向于中性, 前者偏向于 "注释驱动设计和开发", 后者则更多是写好代码, 注释自现

个人对 TDD 的看法比较复杂, 精神上偏向后者, 但 TDD 在真实世界实践中我见到太少, 只在小范围的类库中, 个人项目见到一些.
自己工作中苦 "战术性编程" 久已, 在我的观点上还是做的很多项目, 在设计上在实践上根本不考虑"可测性".
TDD 当时的提出, 就是从代码初期设计开始就优先考虑可测性, 我心向往之, 但做的实践都很小范围. 身边做 TDD 实操的太少, 工作中遗留的屎山, 可测性更是屎, 是 Bug/反馈 驱动的开发, 后边为了所谓指标, 做覆盖率测试, 加的测试代码只能是骗自己的.

我不同意前者书中说的, "TDD 导致战术性编程", 真实世界中并没有太多正反例.

Uncle Bob 说会写新修版的 Clean Code, 希望后边能有机会看到.

感觉关于软件设计的书, 还是太少了 (也可能是我没怎么找到)

[Donne]

TDD 是挺好的，但是我这实际开发过程中基本没时间写测试 case ，就偶尔有点需要方便自行调试才会写个测试用例。