如果代码审查时你忘记了拿近视眼镜

你身处在一个卓越开明的开发团队,你被安排了一整天的时间,什么都不干,只做代码审查。然而,在活动开始两小时前,你发现自己把近视眼镜忘家里了,整个早上你看到的都是模糊的影像和颜色。你该怎么办?

正确的做法是,回家取你的眼镜,因为步行十分钟就能到家,然后今天会跟往常一样愉快的度过。但是,如果说,是你在早上准备离家上班时,发现一群凶猛好斗的大黄蜂在放眼镜的抽屉里筑起了蜂巢,挡住了你拿眼镜的途径,而且它们看起来很不喜欢被打搅。那你怎么办呢?

另一个正确的做法,很显然,是假装你带了隐形眼镜,免得让自己很尴尬。而且你知道自己有不看任何代码细节、只看大概就能说出很多让人钦佩的意见的能力。

代码审查 例一

ex1

我们都认可代码责任应该绝对的分离。任何类都应该只做它自己职责范围内的事情。但是,你的这个 UserCreator很可能有点过了。如果这个 UserCreator对象只做这一点事,那其实Users 对象自己就应该创建自己。另外一点不好的是,创建一个简单的Users,你还需要在成堆的小文件中找出它的创建者对象,不宜操作,也不宜理解。

代码审查 例二

ex2

看看这些一大堆的方法函数,却伪装成一个类,我可以看到,从技术上讲,这些方法都是在各自做自己的事情。虽然没有任何的文字信息提示或暗示,我也能猜出你没有很好的给这个类写测试程序。如果给我一杯浓咖啡、一个下午时间,我想我可以分析出中间这20行的代码是用来判断应该给哪个用户发送邮件,但我还是希望你将这部分代码放到def users_to_send_emails_to函数里,免得我再去动脑子。

代码审查 例三

ex3

很好,在这个类里,你的方法都非常的简洁短小,这是一个进步。然而,你做的是有点过了。虽然Ruby解释器并不在意你的代码逻辑在每个只有一行的方法间来回跳跃,但人脑解释器会在意。也许有人会喜欢上下翻屏看代码,但如果换成我,让我在手臂上记下哪个方法应该调用哪个方法,那我更喜欢将这些小方法组合到一起。

代码审查 例四

ex4

可以看出,你非常关心这个类是否被放在了合适的命名空间里。非常好,使用命名空间是个好事。但在这个文件里,你嵌套了6层。看起来你试图在一个小小的地方里装下太多的东西。你要么应该想想不要分那么多层(是的,我可以看到这里有两个辅助类,应该放到它们自己的空间里,但如果把它放到其它地方会有不好吗?),要么拆分一些代码,放到自己的根空间下。

代码审查 例五

ex5

非常详细的注释,佩服!这段代码需要好几个章节的文字来辅助理解,佩服!

代码审查 例六

ex6

仔细看一下这第二个方法。如果一个方法需要8个参数才能让它知道干什么事情、如何干事情,那么,这个 方法有点太累了。请重构它,从它的肩膀上消减一些负担,拿走一些压力。把它一分为二(或更多),或者,也许将一些参数当成类的初始化参数,可能会更有意义些。这8个参数你会同时都用到吗?所以,不要期望你的方法这样。

所以,这就是当你忘了拿近视眼镜、或直视太阳太久时做代码审查的方法。如果你有丰富的编程经验,我相信你也能举出很多有趣的例子。有人可能会反对,说这些只是一些小事情,还有很多更重要的事情需求考虑。然而,清爽、简洁、良好格式的代码是你需要的,如果你不去用心控制好你的代码结构,它终究会给你带来烦恼。

分享这篇文章:
[英文原文:Code review without your glasses ]

发表评论

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