变量

1. 命名原则是“见名知意”，尽量使用通俗易懂的变量名，而且这个变量名最好是不能有歧义。
2. 好的命名方式，就等于给代码加了一行注释。
3. 各个模块的变量名风格应该统一

2017-08:为了通俗易懂，最近的变量名真是越来越长了，如最近在做的换卡功能。一般来说，变量名越长，就越能体现出变量的含义，但是相对的，长变量会带来一定的麻烦，由于变量名变长，一行代码的长度也会相应地变长。往往因为变量名太长了，导致一行代码写不了多少就要换行了。

2017-08:另外一点就是，各个模块之间的变量名应该尽量地统一，不然后面找代码都会被自己绕晕掉。最近在做换卡换号的时候。差点被各种命名绕晕了。

一开始觉得换卡换号的变量就应该以ChangeBankCard开头，但是后面想了下，除了换卡还有换号，所以后面就又变成了ChangeBankCardInfo，再到后面导致变量名也贼长，eg:ChangeBankCardInfoBizRespDTO，后面应该要将所有的DTO给统一精简一下。

1. 审核类 AuditChangeCard
2. 换卡流程类 ChangeCard
3. 证件资料类 ChangeCardProve

函数

1、函数应该只做一件事。
2、函数的抽象层次一致。

简单来说，就是函数里面不要啥都干。比如下面这样一段业务代码，从方法名上看，这段代码应该是做 计算金额 相关的动作的，可是在方法体里面却操作了DB。这种情况应该把db的操作移到方法外去操作，而这个方法体内只专注于金额计算。

public void calulateMoney() {
  // 计算金额
  int money = .........;

  // 计算结果入库
  moneyDB.updateMoney(money);
}

函数中混杂不同的抽象层次，往往让人迷惑，读者可能无法判断某个表达式是基础概念还是细节，更恶劣的是，就像破损的窗户，一旦细节与基础概念混杂，更多的细节就会在函数中纠结起来。

注释

1、注释不是对劣质代码的补救
2、注释应该是为什么这样做，而不是单单的说明

注释太少也不行哦，毕竟现在写的一般都是 业务 代码，不熟悉业务的人看你写的代码会痛苦的！

代码分片

这个是我个人的代码风格，我比较喜欢这样的代码，如下图，即方法内，每做完一个操作，就进行换行。

public void changeCardProcess(){
  // 换卡事务
  ..........

  // 换卡成功后置操作
  ..........

  // 组装返回数据
  ..........
}

错误异常处理

1. 对错误的处理不要和正常的业务混杂在一起，异常不应该打断业务。
2. 不要返回空，你每返回一个空，那调用这个函数的人都要去做一层空判断。

系统

工厂：封装对象的构造，隐藏构造的细节，使得外部调用者不需要知道生成该类的具体实现。

扩容：

城市由城镇而来，城镇由聚居而来。一开始，道路狭窄，几乎无人涉足，随后逐渐扩宽。小型建筑和空地渐渐被更大的建筑所取代，一些地方最终矗立起摩天大楼。

我们应该只去实现今天的用户故事，然后重构，明天再扩展系统，实现新的用户故事，这就是迭代和增量敏捷的精髓所在。

要做到这种迭代和增量敏捷，你写的程序扩展性必须很强，而不是单单的实现今天的用户故事。

暂时看到这~，感觉这本书讲得十分基础，对于如何写出整洁漂亮的代码有详细的指导。当然，如果你已经有了工作经验，那你的风格可能会和书上的编程风格有很大的相像，因为前人继承下来的好习惯都被你继承了哈哈。

最大的谎言 TODO

你写的 TODO 和 FIXME ，后面真的会去改吗？