何为整洁
书中一开头给出了很有趣的定义：WTFs/min. 即别人看你代码的时候，骂声的多少！:)
所以，何为整洁？一言蔽之，高（效）可读！据统计，代码的读写比例在10:1，可见把代码写整洁，是在节省程序员的生命。好的代码可以自我描述，好的测试可以自证。然而，既然评价代码是否写得好是靠别人的WTFs/min，那是否就意味着这是主观的判断呢？就像诗人李白和杜甫都是写诗特牛逼的人，但他们都有各自的风格，如果有可能让他们“结队”诗，你觉得可能写好么？我觉得可以，但要给他们这样一个任务，如：合作写一首王维风格的诗。其实就是设定一些必要的规范。写程序，当然也有这样的规范。
Clean Code的大致脉络
我整理书中提到的建议大致如下：
如何实施
我觉得简单的代码风格、函数复杂度的检查，可以借助工具，如： JAVA的check style, JavaScript的ESLint, SonarCube的代码检查等等。
而代码的设计是否高效合理，没有人帮得了你，只是靠体提高团队的意识。当然，我们还是有一些面向对象的设计原则可以参考的。如：
- 里氏代换原则(Liskov Substitution Principle, LSP)
- 开闭原则(Open-Closed Principle, OCP)
- 接口隔离原则(Interface Segregation Principle, ISP)
- 它们的目标是：方便扩展，避免重复
- 通常的手法是： 增加、删除优于修改
单一职责原则
- 一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
- 效果： 实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则
合成复用原则(Composition/Aggregate Reuse Principle, CARP)
- 为了避免接口越来越大，难以维护
- 引用好于继承
- Has-A v.s. Is-A
迪米特法则(Law of Demeter, LoD)，也叫最少知识原则(LeastKnowledge Principle, LKP)
- 限制软件实体之间通信的宽度和深度，它的目的是降低系统的耦合度，使类与类之间保持松散的耦合关系
- 减少对象间的相互调用，可以通过引入一个合理的第三者来降低现有对象之间的耦合度。如引用中间协调类的办法来减少相互调用
看了那么多，我觉得或许可以用一条来验证代码是否足够整洁：当你要新加一个功能的时候，你看看代码是新建的多，还是修改原文件的多？这样，你就知道代码是否设计合理，是否需要重构了。
