第一章

第2节 - “不要把问题归咎于别人或其他什么事情上，也不要寻找借口。不要把所有问题都归咎于供应商、编程语言、管理或是同事。这些因素都可能是问题的一部分。它们的确会对解决方案造成影响，但不是给你的借口。”

出了问题，应该优先解决问题，而不是推脱给甲乙丙丁。不利于解决问题。

提示5 - “不要搁置“破窗”（糟糕的设计、错误的决定、低劣的代码）不去修理。每发现一个就赶紧修一个。如果没有足够的时间完全修好，那么就把它钉起来。也许你可以注释掉那些糟糕的代码，显示一行“尚未实现”的信息，或用假数据先替代一下。采取行动，预防进一步的损害发生，表明一切尽在你的掌握中。
……
你或许会觉得，没人有时间来来回回清理项目中所有的碎玻璃。如果你真这么想，劝你还是趁早多想想怎么料理这个项目的后事，或是直接离开是非之地。不要让熵赢得胜利。

之前在某一个项目当中的惨痛经历就是为了过分的追求开发速度，关掉了ts的linter检查，导致了之后出现了大量莫名其妙的问题。最后花费了6人一天的时间去修复所有linter报的错误。还没有计算因为修复linter报错，使一些还没有merge 到主分支的 commit 产生冲突的代码的修复时间。但在之后的一段时间当中，总会有质量开始突发降低的情况。当团队决策：速度 >>> 质量的时候，只能选择离开。

后面举的消防车的例子也很有意思，即使在紧急情况下，比如修复线上告警，也不要轻易的去做“破窗”的事情。例如合入更垃圾（代码质量较差，或者明显有缺陷）的代码。只要有人合入了一个垃圾代码，后面就守不住了。除了原文当中说“随大流”的情况外，还有一种就是当新来的员工，或者是刚进入这个组，由于不了解历史情况或者对代码框架本身不熟悉，就会参考历史代码。当这部分代码被复制、模仿之后（并不是所有人会认真的去阅读之前的代码，或者善意假设合入master分支的代码总是合理的），就会产生新的破窗。之后就越来越难修了。我个人平常更习惯的用语是：“我对代码有洁癖”。