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

但是从清晰度和可维护性来说,还是不推荐这么做。

1、这种代码出现问题后,很难定位哪里出现问题;
2、后续别人维护起来也相当困难;
3、每看一个简单的case,都要跟踪很久;
4、写UT(单元测试)也相当麻烦

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

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

清晰

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

好的命名和注释

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

精准有意义的日志输出

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

代码对称性

例如:

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

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

必要的设计

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

一定要有UT(单元测试)

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

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

余下全文(1/3)

本文最初发表在CSDN,文章内容属作者个人观点,不代表本站立场。

分享这篇文章:

请关注我们:

《编写好代码的几个要素》有1个想法

发表评论

邮箱地址不会被公开。 必填项已用*标注