微信号:programmer_club

介绍:程序员第一自媒体,与你探讨码农人生路上遇到的各类泛技术话题,定期为你推荐码农人生思考、感悟以及启迪!

徒有其表的城市

2016-09-03 22:19 围城莫


众所周知,

网络社会,代码城市,

城市好不好看,

取决于代码好不好。


小编作为未来的网络工程师,现在已经回到寝室的大怀抱,又要开始听老师在上面的絮絮叨叨了。实话说,能不能成网络工程师都是问题,因为代码,写的是真烂。


程序员这一行,算是日日夜夜都在建设网络世界,但总有那么几个异类,不中规中矩的打代码。明明用简单的代码就可以表示的,却使用封装和抽象做,让代码层次很深入。对于这类代码,让人觉得,这是牛逼的代码。




但后来从各方面来考虑之后,这类代码并不推荐。



1这种代码出现问题后,很难定位哪里出现问题;


2后续别人维护起来也相当困难;


3每看一个简单的case,都要跟踪很久;


4写UT(单元测试)也相当麻烦



毕竟代码这个东西,需要从可读性入手,轻松的能看懂代码,如果代码有问题,可以快速定位和修复。我们又不是做底层框架编写,要追求各种设计和扩展性。



下面是业务逻辑代码的一些特性。



清晰


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



好的
命名和注释


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



精准
有意义的日志输出


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

代码对称性

例如:

getInputParameter();

process();

output();

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



必要
的设计


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

一定要有UT(单元测试)

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

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



当你看到一串高深的代码时,不妨从以上几个特性来考虑一下,是否有必要将代码写的那么牛逼,一如徒有其表的城市一样,金玉其外,败絮其中。适合的才是最好的。

程序员e家

programmer_clubs


程序员第一自媒体,与你探讨码农人生路上遇到的各类泛技术话题,定期为你推荐码农人生思考、感悟以及启迪!


▲长按二维码“识别”关注


了解野狗,点击阅读原文“报名”

 
程序员之家 更多文章 盗版软件下的中国 用户体验的重要性 Linux 的小秘密 生前无闻,生后成名 加班真的好吗?
猜您喜欢 Google-LevelDB简介 (七)Android-ObservableScrollView王者归来 奥巴马谈排序算法 拯救友谊的小船 | 友谊的小船如何升华为巨轮 Mysql max_allowed_packet 被修改设置为1GB或者1024B原因