代码审查过程

　　QA审查
　　QA小组很小，不过职责重大，要确保我们的代码满足业务需求，别上来崩溃了。我们使用项目管理工具把PR链接到故事，做QA工作的人进行审查时，可以快速地参考相应的验收标准，以及目标和偏差。他们使用开发者提供的关于测试内容的说明，动用他们自己的能力尝试去击垮系统。如果有什么地方不对了或者没有满足验收标准，他们还是移除所有标签，加上”需要修改“标签，这样在开发者实施修改之后几乎总是会强制带来新一轮的代码审查（通常只是修改部分）。当所有事情都做完，运行良好，代码会得到一个”Passed QA“标签，然后会被合并到我们的发布候选分支。到此代码会终提交给项目master，并在QA和产品团队决定发行版中应该包含的特性和bug修复后提交产品化。
　　如果这些标签的玩意让你迷惑，请看下面的流程图。

　　为什么？
　　流程看起来很多，其实在真实世界里使用起来真的算极其简单了。如果是一次小审查，一个需要尽快完成的特性，整个工作流甚至可以在十分钟内完成。不过通常来说时间会长些，并没有那么急。一切都自然地协作，这套流程确保了我们有三类不同的人群，从不同视角看待我们的代码，确保它有很高的质量并完成应有的功能。这有助于保持我们的代码库和测试的整洁、可读，以及自我文档化。
　　好处可不只是你有了一个流程。我们发布更少的bug，我们对进入代码库的代码满怀喜悦，而且还有人帮助我们每天提高。我无法强调有多少次第二双眼睛阻止了我代码中愚蠢的错误或性能下降。还有QA，在我没有检查的时候，他们救了我无数次。我从未觉得有评论或者批评是带着怨恨或者审判心态的，它们只是坦率的呵护，为了保持代码整洁，为了帮助我修正错误，清理代码，或者学习新的东西。
　　总结
　　在你实际工作中做一些审查的流程吧，或者花点时间去分析，回顾并改进你既有的策略。迭代你的流程，拥抱潜在的变化，因为下一个主意可能更好地改善结果。软件和真人同时审查你的代码，能避免你把愚蠢的错误发布到产品中去，能让你的代码仓库中堆砌的不再是无法管理的代码。