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

英文原文： Code review without your glasses

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

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

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

        代码审查例一

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

        代码审查例二

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

        代码审查例三

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

        代码审查例四

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

        代码审查例五

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

        代码审查例六

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

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