你在一个聪明开明的开发团队，你被安排了一整天除了代码审查什么都不做。然而，在活动开始前两个小时，您发现自己将眼镜落在家里，整个上午您看到的都是模糊的图像和颜色。你该怎么办？正确的做法是回家拿眼镜，因为只需步行十分钟，这一天就会一如既往地愉快。但是，假设你早上准备去上班，发现一群好斗的黄蜂在你的眼镜抽屉里筑巢，阻止你接近它们，而且它们似乎不喜欢被抓住怎么办？打扰。那你会怎么做显然，另一件好事是假装你戴着隐形眼镜，这样你就不会让自己难堪。而且你知道你有能力在不看任何代码细节的情况下，只看大意就说出很多令人钦佩的意见。CodeReviewExample1我们都同意代码职责应该绝对分离。任何类都应该只做它负责的事情。但是，您的UserCreator可能有点过头了。如果UserCreator对象仅执行此操作，则Users对象应该创建自己。还有一个不好的地方就是创建一个简单的Users，还需要在一堆小文件中找到它的creator对象，不适合操作和理解。CodeReviewExample2查看这一堆伪装成类的方法函数，我可以看出，从技术上讲，这些方法各自在做自己的事情。虽然没有短信提示和提示，但我也能猜到你没把这门课的测试程序写的很好。如果你给我一杯espresso和一个下午，我想我可以分析中间的20行代码来确定哪个用户应该发送邮件，但我还是希望你把这部分代码放在defusers_to_send_emails_to函数中，So我不用担心。CodereviewExample3非常好，在这个类中，你的方法非常简洁和简短，这是一个改进。但是，您正在做的事情有点过头了。虽然Ruby解释器不关心您的代码逻辑在每个单行方法之间来回跳转，但人类解释器会关心。也许有些人喜欢上下滚动屏幕看代码，但如果是我，我写下我手臂上哪个方法应该调用哪个方法，那么我更愿意将这些小方法组合在一起。CodeReviewExample4表明您非常关心这个类是否被放置在合适的命名空间中。太好了，使用名称空间是一件好事。但是在这个文件中，你有6层嵌套。看来您正试图在狭小的空间中容纳太多东西。要么你考虑不要那么多层（是的，我可以看到这里有两个辅助类，应该放在他们自己的空间，但是放在其他地方会不会不好？），要么拆分一些代码并将其放在自己的根空间中。CodereviewExample5非常详细的注释，佩服！这段代码需要好几章的文字来辅助理解，佩服！CodeReviewExample6仔细看看第二种方法。如果一个方法需要8个参数才能让它知道做什么，怎么做，那这个方法就有点太累了。请重构它，减轻它肩上的负担，减轻它的压力。将它分成两个（或更多）可能更有意义，或者，也许将某些参数视为类的初始化参数。您会同时使用所有8个参数吗？所以，不要指望你的方法会这样。因此，下面是当您忘记戴眼镜或直视太阳太久时如何进行代码审查。如果你有丰富的编程经验，相信你也能举出很多有趣的例子。也许有人会反对说这些都是小事，还有更重要的事情要考虑。然而，干净、简洁、格式良好的代码才是你所需要的，如果你不小心控制你的代码结构，最终会给你带来麻烦。英文原文：Codereviewwithoutyourglasses翻译自：http://www.vaikan.com/code-review-without-your-eyes/
