前言
《代码整洁之道》在业内有很高的知名度，被诸多前辈推荐给后来者阅读。本书以循序渐进改造一个小程序的方式，演示了一个程序可能的各种设计（在代码层面）。手把手教你该怎么设计代码，为何要这样设计，这样设计的好处是什么。通过一周的阅读，总结了如下要点。
一 函数
所有的编程都是从HellWorld这个小函数开始的，学会设计函数非常重要
函数要短。短才方便阅读、维护和设计。(每个人都经历过读不懂自己代码的尴尬)
函数只做一件事。依照单一职责原则设计函数。一个函数可以:流程控制，逻辑判断，改变变量状态，以及做运算，或者调用多个下一抽象级的函数。
函数分解成多个抽象层级设计，高层函数只调用下次层函数，呈树状图，层层封装。
函数不应该有标识参数(除了作为API的函数)，这意味着函数有至少两种执行方式，违反了第2条原则。而且明显能拆成多个小函数。
函数参数越少越好有，多个参数应该封装成一个整体传入的。如果逻辑上不是一个整体，则函数肯定能被拆成多个小函数然后被分别调用。第4条标识参数可以封装进整体传入函数，而不是直接作为函数的参数
函数真的最好只做一件事，不要为了一时方便顺手加几行代码。如登录验证时，函数用来验证username和password，在验证之后顺便给用户初始化些其他东西。会导致这个函数在其他时候无法验证用户信息。
底层函数不应该改变参数状态，如果想改变某类的状态，就把该函数加入该类，让它自己调用函数。如：把改变类x的状态的函数调用addFooter(x)，改为x.addFooter()。
函数不要返回错误码，这需要你有错误码的枚举类，并且违反了开放封闭原则（你需要加入新错误码来扩展新错误），直接抛出异常就好了。（可以通过继承父异常来扩展）。但是实际上错误码的应用不比异常少，而且异常也会导致代码的臃肿。
函数名称应该描述清楚函数作用，避免频繁去看文档，这对于短小的函数来说不难办到，如果很难命名可能需要思考函数是否有依照以上原则设计(你一个函数可能做了很多事情)。并且名称的命名应该不容易与其他函数名称形成混淆。如：add()在calculator中意思是加，而在List中就不应该用add表示插入集合了，应该用insert或append。简单来说就是一个概念对应一个词，并且始终如一。
二 格式
每个人都有自己的编码风格，书中总结了一些Java及其他语言的建议
好的格式应该由小且精的代码片段（函数）组成
封包代码，导包代码，成员变量，函数方法。都用空行隔开，形成分开的代码块
函数按调用顺序从上到下排列，类变量在顶端声明，方法变量在使用前声明
一行代码不超过100个,同一行的计算可以按先后顺序用空格隔开，如：
100 * 732 / (2+3) * (5-1)
小括号内的运算全都挤在了一起，其他运算都有空格隔开，很容易看出运算顺序缩进代表了一种包含关系。Java没有强制要求，但是python就是用缩进表示包含。
说了这么多最后总结道：老大规定用啥格式就用啥格式
三 注释
其实注释写了后，看的最多的还是自己
- 好代码只需要少量注释，代码就能表达意图——回到之前的内容，这要求我们写小且精的函数。（但这不是你不写注释的理由）
- 好的注释应该是这样的。如：对抽象意图或者深远意义的解释（如我这个函数为啥用这个方法实现）；阐述长且难读的函数（这种难读不是因为代码写得烂，而是业务逻辑复杂）；警示一些关键重要的部分（这些部分一般是函数会改变某些数据实体）；TODO注释提醒并告知未来要做的事；学着公共API的JAVADOC写就是好注释（虽然也有少数烂注释）；
- 烂的注释往往是这样的。如：多余的注释（简单函数强行加上注释，读源码会比注释更快）；误导的注释（注释本来就是错的，可能源自你更新了代码没更新注释——小函数特别可能出现这个问题）；注释掉的代码（你为何不删了代码？）；废话太多的注释（语文是体育老师教的）。
四 类
书中对于函数的设计其实和类的设计思想是类似的，所以类应该功能单一且小巧，越小耦合性越低，最后用门面模式组合起来向外提供API就好了
五 系统
系统整体结构的设计
- 把系统的整体构造和业务使用分开。不要让构造影响使用，也不要让程序的运行反过来影响构造。这也是Spring这么应用广泛的原因之一，Spring Core就是个类容器。
- 把业务逻辑和检查或日志方案分离，不然纠缠在一起的代码会很难看懂和修改。Spring AOP也解决了这个问题。
六 测试
测试不仅仅是测试小姐姐的事情
- 测试函数（方法）也应该短小（如果函数原本够小的话测试函数自然会小）
- 每个类最好都测试下，测试时间会比以后debug时间少。从底层函数一点点测上去，以后debug能迅速定位。
- 测试类应该保存下来，方便每次修改后进行测试
