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

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

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

代码审查 例一

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

代码审查 例二

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

代码审查 例三

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

代码审查 例四

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

代码审查 例五

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

代码审查 例六

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

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

   请阅读全文：如果代码审查时你忘记了拿近视眼镜。

   本文由外刊IT评论网(www.vaikan.com)原创发表

   文章地址：如果代码审查时你忘记了拿近视眼镜，

   [英文原文：Code review without your glasses ]

建议继续学习：

1. 谷歌是如何做代码审查的    (阅读：5720)
2. 代码审查：ThoughtBot官方给出的代码审查指导原则    (阅读：3520)