代码简洁之道-总结

从8月13号拿到这本书，历时两个月认真看了一遍，书中给了很多实用的建议，也以代码的方式展示了具体的优化方法和步骤。
书中1-13章每章都有一个具体的点，逐个分析优化代码需要注意的地方。
读到第14章的时候，我崇拜的两个大牛给了建议，一个说代码还是要多写，写的多了发现不合理的地方的自然的就会想办法改进；一个建议我应该去读源码，从源码中学习解决问题的方式和思路，而不是还在看这些基础的书，源码看多了自然也就知道怎么更好的写代码和优化代码了。我听从了建议，在十一期间，我下载了spring的文档和源码，开始研究spring bean。但是，心里总觉得有件事情没有做完，没有探个究竟，有种半途而废的感觉，所以就计划拿出一个星期的时间把剩余部分看完。
第14章的逐步改进，我按优化步骤，敲了4个版本的代码，跟着作者逐步优化代码，把优化的心得写在了注释里，在这里。
第15和16章，类似14章，分别针对一段程序做优化，15章里选了SerialDate的源码进行优化，跟随作者的思路，能按照1-13中提到的方法切割重组优化代码。
第17章是对整本书的总结，可以说是优化代码的66条童子军军规（包括7个方面：注释、环境、函数、一般性问题！、Java、名称、测试）。

我认为对我最有用的建议

关于重复

重复的代码都代表遗漏了抽象。重复的代码可能成为子程序或干脆是另一个类。将重复的代码放进类似的抽象，增加了你的程序语言的词汇量。其他程序员可以用到你创建的抽象设施。而且由于你提升了抽象层级，编码变得越来越快，错误越来越少。
最明显的形态是你不断看到明显一样的代码，可以用单一的方法来代替。
较隐蔽的形态是不同模块中不断重复出现、检测同一组条件的switch/case或if/else链，可以用多态来代替。
更隐蔽的形态是采用类似的算法但具体代码行不同的模块，可以使用 模板方式或 策略模式来修正。（多数设计模式都是消除重复的有名手段，OO自身也是组织模块和消除重复的策略。）

类的层级

基类和派生类，较高层级不依赖较低层级派生类的概念。
例外情况是，派生类数量严格固定，基类中拥有在派生类之间选择的代码，在有限状态机的实现中这种情况很常见。然而需要注意的是，这种基类和派生类紧密耦合的，只是部署在同一个jar文件中。
一般情况下，我们是希望派生类和基类部署到不同的jar文件中，确保基类jar文件对派生类jar文件的内容一无所知，我们就能把系统部署为分散和独立的组件。当修改派生类时，不需要重新部署基类。这意味着大大降低了修改产生的影响，从而使维护系统变得简单。

精简设计

设计良好的模块有着非常小的接口，不依赖很多函数，耦合度较低，让你事半功倍。而设计低劣的模块有着广阔、深入的接口，需要依赖很多函数，耦合度较高，不得不事倍功半。
限制类或模块中暴露的接口数量。类中的方法越少越好，函数知道的变量越少越好，类拥有的实体变量越少越好。
隐藏你的数据，隐藏你的工具函数，隐藏你的常量和临时变量。不要创建拥有大量方法或大量实体变量的类。不要为子类创建大量受保护变量和函数。尽量保持接口紧凑。控制耦合度。

注意边界条件测试

我们要关注的不只是代码的逻辑，更要注意运行时的状态和判断条件执行情况，通常完备的单元测试是必须的。

注意没有物理耦合的逻辑耦合

如果一个模块依赖另一个模块，依赖就应该是物理上的而不是逻辑上的。这个字面上不太好说清楚，请参考书中P265中的优化步骤。

用枚举的抽象方法重构switch

重构switch的方法，一种是用多态，可以参考我上一篇博文；一种是用枚举的抽象方法，在枚举的每个属性中实现该抽象方法，使用时可以直接调用。

数据和对象的反对称性

需求中会需要添加新的数据类型而不是新的函数–>使用对象和面向对象（基类和多态）。
添加新的函数而不是新的数据类型。–>使用过程式和数据结构。

函数参数要少

最理想的是没有参数，其次是一个，再次是二，尽量避免三。因为测试时的排列组合用例太多了。

函数要短小

每个函数只做一件事。
作者建议：每行100字符，不超过20行。

注释要精简

只解释意图。避免罗列历史版本，那是版本管理工具做的事情，避免日志式注释，避免废话和误导，避免保留注释掉的注释。

及时清除死代码

不要手软。