编写好代码的几个要素-控件新闻-慧都网

编写好代码的几个要素

转帖|行业资讯|编辑：郝浩|2016-09-05 14:25:46.000|阅读 190 次

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

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

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

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

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

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

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

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

例如：

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

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

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

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

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

本文转载自techug.com

标签：

本站文章除注明转载外，均为本站原创或翻译。欢迎任何形式的转载，但请务必注明出处、不得修改原文相关链接，如果存在内容上的异议请邮件反馈至chenjj@evget.com