编写业务逻辑代码,清晰可维护是很重要的

最近经常做业务逻辑代码review的工作,发现各种风格的代码,其中有一种是封装和抽象做的非常的多,代码层次非常的深入,表面给人感觉是:牛逼的代码。但是从清晰度和可维护性来说,还是不推荐这么做。

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

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

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


清晰


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


好的命名和注释


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


精准有意义的日志输出


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


代码对称性


例如:

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


必要的设计


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


一定要有UT(单元测试)


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

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

打赏支持我写出更多好文章,谢谢!

打赏作者

打赏支持我写出更多好文章,谢谢!

2 6 收藏 4 评论

关于作者:Sam哥哥

互联网技术爱好者,目前就职于广州知名电商企业。个人的csdn技术博客如下:http://blog.csdn.net/linsongbin1本人伯乐在线的文章,都出自这个csdn博客 个人主页 · 我的文章 · 15

相关文章

可能感兴趣的话题



直接登录
最新评论
跳到底部
返回顶部