书的示例是Java语言编写的，虽说不会影响阅读，但是后面几章讲应用这套方法论的时候，大篇幅的Java代码分析还是挺难受的，而且连java测试框架Junit都要细讲，对于非Java系的开发者来说，一些内容确是云里雾里。
书的前2/3能够适用全部的开发者，读完有很大收获。后面1/3讲到依赖注入，AOP等内容，这已经是Java的高级理论了，没有基础的读者理解起来还是比较费劲的。还有就是自动化测试是为开发者提供了很好的重构基础，不过这个实践还是需要在大公司才有机会尝试。
以下总结了一些自己阅读时的一些要点，虽然还未来得及切身实践，拜读之时却也颇有感受，这种书还是要反复阅读，实践之后会有更多体会。

代码整洁之道

• 程序员遵从不了解混乱风险的经理的意愿，也是不专业的做法
• 整洁的代码只做好一件事
• NameString会比Name好吗？难道Name会是一个浮点数不成？
• 明确是王道
• 类名不应当是动词
• 给每个类添加“GSD”前缀就不是什么好点子，为什么要搞得IDE没法帮助你？
• 函数的第一规则是要短小，第二条规则是还要更短小
• 函数应该做一件事，做好这件事，只做这一件事
• 对于switch语句，我的规矩是如果只出现一次，用于创建多态对象，而且隐藏在某个继承关系中，在系统其他部分看不到，就还可能忍受
• 标识参数丑陋不堪，宣布本函数不止做一件事，true or false
• 当一组参数被共同传递，就像point的x、y那样，往往可以从参数创建对象，从而减少参数数量
• 最好把try/catch代码块的主体部分不分抽离出来，另外形成函数
• 我并不从一开始就按照规则写函数，我想没人做得到
• 别给糟糕的代码加注释——重新写吧
• 直接把代码注释掉是讨厌的做法，别这么干
• 你今天编写的功能，极有可能在下一版本中被修改，但代码的可读性却会对以后可能发生的修改行为产生深远影响
• 类并不简单地用get和set将其变量推向外间，而是暴露抽象接口，以便用户无需了解数据的实现就能操作数据本体
• 过程是代码便于在不改动既有数据结构的前提下添加新函数，面向对象代码便于在不改动既有函数的前提下添加新类。
• 对象暴露行为，隐藏数据；数据结构暴露数据，没有明显的行为
• 当错误发生时，程序员有责任确保代码照常工作
• 如果无法为某个类命以精确的名称，这个类大概就太长了
• 系统应该由许多短小的类而不是少量巨大的类组成
• 通常而言，方法操作的变量越多，就越粘聚到类上（内聚UP）
• 软件项目的主要成本在于长期维护
• 对象是过程的抽象，线程是调度的抽象