《Clean Code》读后笔记
这是一本讲如何写好可读性高代码的书，可读性高意味着维护性高，开发软件有80%的时间处于是在维护阶段。写好干净的代 码，不仅是给他人好处，也是给自己方便，因为我们也要维护/阅读自己的代码。看完这本书再翻一下Kent Beck的《Implementation Patterns》（不过写的很枯燥生涩），讲的是同一个话题，但是感觉后者写的书读起来味如嚼蜡，觉得Kent总喜欢把一些简单概念抽象化讲，也许需要 有一定开发积累才能享受他的书吧 (不过，amazon上对Kent此书的评价也很低)？ 相比之下《clean code》更加直观，读起来让人觉得享受，读完之后几天就马上把他的一些建议应用到我自己的代码中。以下是一些书中提到的建议参考：
- 与其写啰嗦的注释，不如重构代码（比如重命名方法名，变量，或者把代码分离到不同方法）来替代没必要的注释
- 方法参数越少越好，除非有人逼你这么做，不要超过2个参数。当你发现你非用2以上参数不可，考虑把一部分参数抽象出来做一个类。
- 用给自己孩子起名一样的谨慎心态给变量，方法起名。
- 自上向下的代码放置规则：先放置首层抽象级别的第一段代码，而后紧跟其相关的第二抽象级别代码，如果有第三层继续。 依此类推，便于他人以逻辑顺序从上到下阅读
- 同一方法中的语句都要在同一抽象级别
- High Cohesion 能给代码带来良好阅读性以及维护性
- try, catch 最好不要嵌套，如果有就把嵌套的那部分try,catch抽离出来到一个抛出异常的方法中。
- The Law of Demeter, 代码模块不应该了解其操作的对象的内部结构, 也就是说她不应该调用任何方法返回的对象的方法（也就是“连续调用”), 应该把那段“连续调用”抽象到一个方法中，从而隐藏其结构
- Open for extension, close for modification.
- Dependency Inversion Principle, DIP, 类应该“依赖”于抽象，而不是具体实现。 这样子可以减少耦合
- 所谓边界，使用第三方代码的时候，需要把原来API做适当包装，只暴露一些我们期待用户使用的接口，隐藏一些不需要的接口。利用适配器模式。
- 高内聚意味着类中的变量都最大程度地被每个方法使用，应该保持类的高内聚性。单一职权原则(SRP) 的结果是，分离出很多短小精悍的小类。
如何写出这样的整洁代码？没人可以，一开始都没办法一蹴而就，而是写完代码之后再打磨，在提交代码之前把代码整理，重构.
