《CleanCode》第一章

《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。用人类可读的方式来写代码。

整洁的代码是作者着力着凉的代码。在意。

同一段代码如果反复出现，代表某种想法并没有在代码中得到良好的表现。

消除重复和提高表达力。

对于一个明确、通用、有多种实现方式的功能，可以面向接口。这样可以先用简单的方式实现，同时可以为未来的修改留下余地。