蕲春人的博客

About Blog Email GitHub

18 Apr 2011
怎么样写好的ruby业务代码

标题很强,心中却很烦乱,写下这个解解闷,吐吐苦水。

最近与一个小Ruby程序员共事,交流起来还没有什么问题,可是看他写的代码,虽然坏不到哪里去,但我还是心里一阵阵反感,这和我平时阅读从github 上拉下的代码的感觉是完成不一样的。

给我不爽的地方有:首先他在用程序员的思维写业务代码。这一点虽然对程序的最终运行结果没有什么影响,但我是非常反感这一点。我一直对自己说,我要写可读的英语的,并且本身能说明它是要做什么事情的代码,尤其我是当在做电子商务方面的业务系统。

我们应该站在设计人员的角度来写代码。我们是整个系统的设计师,控制人员,管理人员,我们可以通过代码的方式为系统来设计各种业务规则。而不仅仅是为了用程序代码来码完业务操作。这种特点的典型特征就是在程序中(特别是在model 中)有很多这样的方法命名,如update_xxx, delete_xxx, set_x_to_y,这种类似的命名,它就是纯粹的数据操作,而不是用代码来表达业务!

都说程序要写耦合内聚什么的,模块化啦,抽取啦,减少重复,但是在这之间把握一个平衡还是要有很多磨练的。我之前一些时候在写Rails代码时就时常被这个问题折磨过,心里总是努力想把代码写得好一点,可最终完成业务目标时,看着自己的代码总是感觉不对劲.

不劲的地方有:

总是在考虑“我这段代码到底是单独抽出来呢,还是就这样放在其中呢”,“我感觉这个命名怎么那么别扭啊,哪里不对了?”等等之内的问题,然后花时间在这些代码段之间穿梭。其实我现在想明白了。要想让自己写的代码(我这里尤其是处理业务逻辑的代码)看得明白,读得顺畅,要把握好几点。

第一,要记得上面第一条中说到的。

第二,英语表达要不能太糟糕。 他英语不太过关,写的一些代码都是去google翻译查的,这我还是不说什么,可以有的翻译真的好离谱啊,再加上他自己的一些润色,完全可以我把搞迷糊。

第三点,要清楚业务需要的实质,明白什么是将来可能变化的,什么是肯定不变化的。明白了这一点,就知道一个业务操作中,到底是应该把方法怎么折分。不变的代码,就都写在一个方法中也是没有问题的,即实代码长一点,那样整个操作是一个整体,到时时候维护起来会很明了。

第四点,对于业务操作的方法,一般写得内聚紧凑一点很是没有什么问题的。不要惦记什么一个方法不能超过多少行代码的信条。

第五点就是测试了,这个一定得搞。


蕲春人 at 21:12

scribble

About Blog Email GitHub