怎么读到这本书的
从18年底，我开始lead一些预研的项目。日常的工作中，需要深入了解各个模块，并且要搭建项目的架构。这些工作都需要在非常有限的时间里面高质量完成，他们所要求的技能同individual contributor大有不同，所以找了些书看弥补自己在技术/知识之外的不足。而本书正是讲程序员如何进一步磨练自己的技艺并提高工作效率。
感想
这本书可以类比于《编程珠玑》：
- 各个章节之间没有紧密的逻辑联系，更像是一篇篇专栏文章。
- 各个章节就像颗颗珍珠，从几十年的实践经验中磨砺而成。看到每颗珍珠时，如果你也有类似的经验，就会由衷的说：多么痛的领悟啊！
- 读起来毫无压力：就是跟大家交流工作经验一下嘛，没有什么标准答案。
如同《编程珠玑》的核心是实用算法，本书也有唯一的中心：咋样才能把代码写快写好呢？举几个例子：
破窗理论：项目压力大的时候，大家就想尽快把代码checkin到主干。这样的话，解决代码冲突/调试各种奇怪bug的风险就转嫁给下游了。在这种利益驱使下，代码的质量就会严重下降：管它像不像是块破补丁，能跑就行了。如果没有一个严格的gate keeper，项目就会如同下坡路上踩了油门一样：我看到烂代码被checkin了，说明大家对质量不在乎，所以我也不在乎。到最后呢，就是多了一个破败不堪被人抛弃的小镇。
最有前途的银弹是啥？prototype。正是暗合了《人月神话》中的启发。
其次呢？把
assert保留在release build里面。很多人会对此嗤之以鼻：你不管performance了吗？说真的，很多时候客户最看重的是你的软件不要给它添乱。在qualification的时候发现的bug，你如果调的太慢了，客户根本就不会让你到performance测试那一关。再者说了，关键路径上多些assert就把performance拖累了？你确定吗？解耦：任何时候，只要两个东西共享了什么，他们就耦合在一起了。所以解耦的关键就是：模块A真的需要知道模块B的一个细节吗？
如何应对变化的需求：细节应该依赖于核心逻辑，而不是反过来。如果你核心也多变的话当我没说😄该换甲方了亲。
怎么读这本书
有空了就翻一遍。
