彩票走势图

最近经常做业务逻辑代码review的工作，发现各种风格的代码，其中有一种是封装和抽象做的非常的多，代码层次非常的深入，表面给人感觉是：牛逼的代码。

但是从清晰度和可维护性来说，还是不推荐这么做，理由如下：

• 这种代码出现问题后，很难定位哪里出现问题
• 后续别人维护起来也相当困难
• 每看一个简单的case，都要跟踪很久
• 写UT（单元测试）也相当麻烦

我个人认为编写业务逻辑代码还是要从可读性入手，轻松的能看懂代码，如果代码有问题，可以快速定位和修复。我们又不是做底层框架编写，要追求各种设计和扩展性。

下面列举我觉得是清晰可维护的业务逻辑代码的一些特性。

清晰

虽然面向对象讲究内聚和封装，但是太多的子方法和类，实在是会把人绕到头晕，我推荐的做法是，方法尽量的内联，是同一个业务的就通通放到某个方法里面，如果这段逻辑实在太长，可以考虑抽取一些子方法(尽量别太多)。至于类，别动不动就来个类封装一把，要避免类膨胀。

好的命名和注释

现在网上的一些文章流行去除所有注释，通通用一个好的方法名字表达即可。这种做法我个人是很反对的。虽然方法的命名极其重要，但是写业务逻辑代码，必要的注释还是要的，另外的同事阅读代码的时候，也比较容易读懂代码的意图。

精准有意义的日志输出

如果从事过互联网项目的同学，应该有一种深深的体会，线上出现问题，除了看各种监控系统之外，就是看日志了。日志的输出必须是有意义准确的，尤其是 异常日志和业务日志。好的日志输出，可以快速定位问题并快速解决。如果解决一个问题要一个小时的话，有可能公司就损失几百万了。

代码对称性

例如：

getInputParameter();
process();
output();

这种就属于代码的对称性。

必要的设计

只是简单的根据业务场景直白的编写代码也是不可行的。必要的设计可以带来更加清晰的代码结构。

一定要有UT（单元测试）

没有UT的代码实在是太恐怖了，尤其是互联网应用的代码，稍微出点问题，公司就有可能损失一大笔钱。

编写ut的时候，至少一定要把重要的流程覆盖到，万一代码有问题了，也只是小问题。再者，由于需求的变更，原来写好的代码还需要再次改动，如果你没有ut覆盖的话，可能影响原来代码的功能。ut可以带给我们信心。另外UT也可以促进你编写清晰的代码。

本文转载自