今天你 CR（code review）了吗？
CR ？哈哈，并没有。
老实说，就是自己写的代码，过了一段时间后，再去查看，也会很惊讶的说：这是我写的吗，也太不规范了吧。这首先说明了我在进步，其次，之前写的代码是有问题的。那就引出了一个问题，之前怎么没有发现呢？
对于自己写的代码，会潜在地产生一种信任和依赖，所以自己有时候是很难发现其中的明显的错误以及规范问题的。然而，对于其他人来说，一开始是不会进入这种 “自我信任” 状态的，所以较容易发现问题。CR就创造了这个机会，以第二双眼睛再次检查代码，帮助我们及时地发现潜在的问题。
有没有遇到过以下情况：因为一个非空判断而查找了好久；因为变量命名不规范而吐槽；因为关键参数没有添加说明，然后询问团队成员，但却被告知，相关人员已经离职了......诸如此类，其实大部分在CR的时候就能够发现并规避了。如果之前这样做了，现在根本就不用花费这么大的成本去还这些代码债务了。
CR分为正式代码评审和轻量级代码评审。后者更加便捷，也是经常被采用的。我们需要根据自身所处的环境进行选择，适当调整实践的方式。CR的主要目的是为了提高代码质量以及团队内部知识共享，提升团队的整体水平，并不是借此机会以缺陷和错误来批判他人。一直相信这一点，CR是不需要花大量的时间来执行的，但效果却是很显著的。
意识到CR的重要性后，怎样正确有效的实践CR也是很重要的。
Code Review的最大的功用是纯社会性的。如果你在编程的时候，知道将会有同事检查自己的代码，那编程的态度就完全不一样了，写出的代码将会更加整洁，有更好的注释，更好的程序结构。若没有代码审查，尽管还是会有人看到你的代码，但这种事情不是立即发生的事，谁知道是哪个时间点(so，you don't care)，并且它不会给你带来同等的紧迫感和重视。
实践CR之前，团队成员间需要达成一个共识，制定一份合理的代码规范标准。以此为前提，后续再补充。代码规范与代码优化一定要区分开，不可相提并论。作为一个审查者，你的任务不是确保被审查的代码都采用你的编码风格，因为它不可能跟你写的一模一样，而是要确保被审查的代码的正确性。
其次，这是一个长期实践，不能中断，并且每次所用时间不宜过长。这是一个循序渐进的过程，不可能一次性到位。我们需要跨出最难的第一步，然后逐步解决遇到的 ”拦路虎“，不能因为各种各样的理由，就此中断。
实践CR的目的是服务于我们，不是以此为机会去打压他人。对于他人的代码，不是一定要做出评论，表扬或是批评，以突显自己的存在感。并且，这不仅仅是个人的事情，更应该是团队层级的，最主要的目的是为了提升团队的整体水平，保证代码的高质量。
