代码整洁之道
代码整洁之道
一、整洁的代码
1.混乱代码的危害：坏代码很难维护，导致后面完全无从下手，导致生产力下降。增加新人又不了解最初设计，让生产力不断趋向零。
2.坏代码我们不应该抱怨：需求变化背离初期设计、进度太紧张没法好好优化代码。因为护卫代码是程序员的基本态度。
3.童子军军规：让营地比你来时更干净。每次的清理工作也许很轻松：也许只是改好一个变量名、拆分一个过长的函数、消除一点重复的代码、清理一个嵌套的if语句。
二、有意义的命名
1．好的命名相当于注释
2．做有意义的区分：moneyAmonunt和money、customerInfo和customer、accountData和account、theMessage和message
3．要用读的出来的名称：杜绝像：zljclsj（滞留件处理时间）
4使用可搜索的的名称：定位精准
三、函数
1．函数的第一规则是要短小
2．只做一件事
3.每个函数一个抽象层级：抽象层级不一样，导致函数的职责不清晰
4.自顶向下读代码：向下规则
5.switch：违反了单一职责、开闭原则。可以使用多态代替
6.使用描述性的名称：长而具有描述性的名称要比短而令人费解的名称好。函数越短小、功能越集中名称更容易概括
7.函数的参数最好不超过2个
8.不传标识参数：会打破单一职责
9．使用异常代替错误码
10.抽离try/catch代码块
11.处理错误就是一件事
12.别重复自己：代码的复用
13写出好的代码都是从初稿一直不断的重构而来的。没有一蹴而就的，因为没有人做得到，除非把熟悉无比的代码直接搬出来。
四、注释
1.最好的注释就是间接易懂的代码。因为如果要修改功能的话尽管看了注释我们还是要去代码中确认一遍注释中所讲的。只不过我们把代码当做代码阅读的辅助工具。
2．有一些必要的注释：法律信息、提供信息的注释、对意图的解释、阐述、警示、TODO注释、放大、公共API的Javadoc
3.坏注释
3．1喃喃自语
3．2多余的注释
3．3误导性注释：描述不准确
3．4循规式注释(方法上方的参数含义注释)：这种目前我项目组是要求的。
3．5日志注释(方法每次修改注明时间、人员、改动)：这种目前我项目组是要求的。不过我觉得每次改的时候如果当前的函数功能和前面的日志注释有冲突要适当删除前面的日志注释。这样保持日志中的注释和函数保持一致。
3．6废话注释：一些显而易见的就没必要，比如构造函数注释里面写一句“这是构造函数”。
3.7 可怕的废话：
3.8能用函数或变量时就别用注释：正如上文所讲，最后的注释就是代码本身。
3.9标记栏不要滥用，否则失去了标记栏着重本身的意义
3.10注释掉的代码都删掉：98%不会再用了。况且现在都有代码管理系统
五、格式
1.缩进、对齐、类不要行数太多、行不要太长100字符
2.团队规则：一个开发团队要统一一套编码规则
六、对象和数据结构
1.对象中不要胡乱给变量加赋值器和取值器，这样和公共变量无异。这样会暴露数据细节，应该以抽象形态标书数据。
七、错误处理
1.处理异常而非返回码
2.先写TRY_CATCH_FINALLY语句
3.使用不可控异常
4.给出异常发生的环境说明
5.依调用者需要定义异常类
6.定义常规流程
7.别返回null值
8.别传递null值:有可能得到运行时错误
八、边界
1.使用第三方代码：使用边界接口避免从公共API返回或者作为参数传递给公共API。因为这样有时候会导致边界不清晰的问题。
2. 8.2浏览和学习边界和8.3不全
4.学习性测试的好处不只是免费：要学习性测试
5.使用尚不存在的代码：适配器
6.保持整洁的边界，包装接口，不要过多依赖别人的接口，或者用适配器模式链接
九、单元测试
1.TDD三定律：
定律一:在编写不能通过的单元测试前，不可编写生产代码
定律二：只可编写刚好无法通过的单元测试，不可编译也算不通过；
定律三：只可编写刚好足以通过当前失败测试的生产代码；
2.保持测试整洁
3.整洁的测试
十、类
1.类的组织
2.类应该短小
2.1单一权责原则
2.2内聚
2.3保持内聚性就会得到许多短小的类
2.4为了修改而组织
十一、系统
- 管理系统层级
- 将系统的构造与使用分开：降低全局的依赖性、遵循单一职责原则、依赖注入
- 扩容
- Java代理
- 纯JAVA AOP框架
- Aspectj的方面
- 测试驱动系统架构
- 优化决策
- 明智使用添加了可论证价值的标准
- 系统能够需要领域特定语言
十二、跌进
- 通过跌进设计达到整洁目的
- 简单设计规则1：运行所有测试
- 简单设计规则2~4:重构：重构的规则：消除重复、保证表达力、尽可能减少类和方法的数量
- 不可重复：代码的可复用性
- 表达力：好的命名、短小的函数
- 尽可能少的类和方法
十三、并发编程
十七、味道与启发
