命名规范
名称的长短应该与其作用域大小相对应。比如 一个随处可使用的静态方法或者静态变量 名称可以长一些。 一些函数内部使用的 变量，名称就可以短一些。 如果是一些循环要使用的变量 那么可以简单的使用一个字母来表示，** 但是尽量不要使用字母e， 因为字母e是英文中最常用的字母，搜索的时候会比较麻烦。
函数定义
超过三个case的 switch语句 最好使用策略模式来优化。函数尽量要短小。尤其是函数参数 不要超过3个，超过3个参数的 函数 理解起来就比较困难了。可以考虑将一些参数 合并成一个。
不要定义有副作用的函数
这个就是一个反面教材， 一个检查密码是否合法的函数，竟然隐藏着 session init的 逻辑。 这种函数 副作用极大。 因为多数人在版本快速迭代的时候是不会检查每个函数里面的实现的。
我自己就被类似的函数坑过。
所以大家定义函数的时候 最好职责还是要单一些。只做你函数名指名的事情 多度的事情不要做。
使用异常来代替错误码
错误码 在单层逻辑的时候 是比较好使的方法 但是一旦到了多层逻辑 错误码的形式就比较讨厌了，不好使用也不好维护。
例如：
这样的代码 维护起来成本就很高了。尤其是在表单输入验证，或者级联进行crud的时候 很容易出现。
我们换一种方法来实现
错误码不要使用enum
例如：
这样的错误码就很有问题， 日后每次对这个错误码的类进行升级的时候 依赖他的模块都要重新编译。耦合就太高了。 其实这里 就用自定义的异常就可以了。 日后有更新 只要extends 老异常 得出来一个新异常即可。
坚持维护注释
这点非常重要，相信大家都有过体会，在维护一些老代码的时候 经常会碰到 代码的注释和代码本身的含义 完全不同的情况。 所以这里 强烈建议 一定要坚持维护注释。 代码有变更的时候 不管之前的代码是不是自己写的，但是这次改过了 就应当 尽量修改注释。 否则对后人的维护非常不利。
另外不要因为自己写了注释 就可以把对应的函数或者是类写的很烂，我发现很多人都有一种思想，我写了注释了，所以这个函数不管有多复杂 他都是合理的。 这个思想是不对的。
保持干净的DTO
这个应该很多人都知道了，DTO里面 不应该包含任何的业务逻辑。
不要返回null值
不管在任何时候我们写出来的函数都不要返回一个null 值，这会增加系统崩溃的概率。 尤其是对于返回list的情况， 如果找不到数据 就返回一个 没有数据的list 而不要返回一个null。
时刻检验函数的入参是否为null
在写公共函数的时候 一定记得时刻校验 函数参数是否为null，因为你无法保证别人到底会怎么调用你的函数。 但是这里依旧建议，如非必要 请不要将null 作为参数传递。
掩蔽时序耦合
这个原则 也是最近触发了一次线上故障以后 才真正理解的。 某些时候 我们的某些操作 其实是带有时序性的， 比如 做饭这件事。 他总是 遵循 买菜-洗菜-切菜-开火-炒菜 这5个基本步骤。
假设你的函数写成这样：
这个其实很难看出来 他们是有上下级依赖关系的，维护起来 万一打破了这种关系 很容易发生故障。 对于这种强依赖的顺序关系，我们其实可以依靠 返回值 来将他们串联起来。
例如：
这样每一步都依赖上一步的返回值 则可以明确的绑定依赖关系。
