书写业务逻辑的优等式（Java篇）

有一种牛逼的代码他有多牛逼呢，封装和抽象做的非常的多，代码层次非常的深入，看似牛逼，实则没有注释估计过一个月自己写的什么玩意都忘记了。

从清晰度和可维护性方面来说，有以下几个弊端~

1. 出现问题后，很难定位哪里出现问题；
2. 后续给他人维护起来也是相当滴困难；
3. 每看一个简单的Case，都要跟踪很久；
4. 写单元测试那是相当滴麻烦；

类名也不宜过长，比如看下面这位~

优秀滴业务代码七步曲

• 方法尽量的内联，是同一个业务的统统放到某个方法里面
• 清晰的命名和注释说明
• 输出有意义的日志
• 必要的设计
• 代码对称性(输入 -> 处理 -> 输出)
• 通用代码不可取，可能会迁一毁百
• 最后，别忘了单元测试和必要的伪参测试