《Clean Code》第一章
1.1 要有代码
要关注模型和需求，也要关注代码。
代码呈现了需求的细节。编程，就是将需求明确到机器可以执行的细节程度。
我们造不出能满足客户模糊需求的系统：需求规约原则告诉我们，规制良好的需求就像代码一样正式。
代码是我们最终用来表达需求的语言。
1.2 糟糕的代码
糟糕的代码能让项目毁灭。赶进度出产品，特性越加越多，代码越改越乱，最终导致没法管理代码。最终导致发布周期变长、崩溃率增高、加载时间过久。
勒布朗定律：稍后等于永不。
就是说，Later 的 Bug 基本不会改。。。
1.3 混乱的代价
随着混乱的增加，每次改一点代码，都得影响其他两三处。每次加一点代码，必须对现有的一堆代码非常了解。也就是说，混乱的增加会降低团队的生产力。而这种降低，只通过加人可能并不能有太明显的改观。因为新人不熟悉系统，可能会带来更大的混乱。
新人可能搞不清楚，什么样的修改符合设计意图，什么样的修改违背设计意图。
（所以 Code Review 是非常重要的）
1.3.1 华丽新设计
老系统陈旧。于是一堆开发者献策，要推翻重做。但是新系统必须得实现之前老系统的所有功能，所以会导致周期非常长。
1.3.2 态度
程序员遵从不了解混乱风险的经历的意愿，也是不专业的做法。
1.3.3 谜题
制造混乱并不能让你赶上工期。
赶上工期的唯一办法，就是尽可能保持代码整洁。
1.3.5 什么是整洁的代码
尽量减少依赖关系
分层
整洁的代码只做好一个事情。
整洁的代码犹如优美的散文。
整洁的代码从不隐藏设计者的意图，充满了干净利落和直接了当的控制语句。
整洁的代码可以由作者之外的开发者阅读和增补。可读性，可改性。
做一个事情，只提供一种途径。
函数越小越好。
字面编程：Literate Programming。用人类可读的方式来写代码。
整洁的代码是作者着力着凉的代码。在意。
同一段代码如果反复出现，代表某种想法并没有在代码中得到良好的表现。
消除重复和提高表达力。
对于一个明确、通用、有多种实现方式的功能，可以面向接口。这样可以先用简单的方式实现，同时可以为未来的修改留下余地。
