在编码之后加入的复查阶段，让很多人不理解，因为大家没有在编译之前再读一遍自己代码的习惯，总是希望编译器来代替自己查错。不错，已经有许多改进的编译器可以查出全部的语法故障，和一部分语义故障；但是最好的编译器也只能查出85%的故障，所以为了尽量早地发现故障，作者自己的复查是有价值的。妄图借助后续的同行评审来弥补没有自己复查的人，忘记了自己才是作品的构思者，才最清楚自己想要表达什么，这是任何别人代替不了的。
不过，如果研发规范在操作这一步骤中面临很大的推进困难，也可以调整此操作到编译之后，但是取消是不提倡的。
复查也同样需要规范的指导，即代码复查表。这张表的制定需要更多的实时性，它一般是根据软件团队对某一种语言的运用程度而定制的，甚至个人也可以根据个人掌握情况来调整。检查表的有效程度，可以用此阶段的发现故障数量，与整个研发过程的故障数量之比度量，因此它依赖于后期的质量检测，如果在前期制定时有经验丰富的工程师参与，将会降低延迟修复故障而造成的成本。
从图中可以看出，代码复查可以进行多次，理论上依赖于作者对完成代码的质量信心，不过一般更依赖于作者的勤勉和负责程度，需要团队领导和质量经理经常督促。
3． 编译
这是个没有争议的操作，基本上所有的代码版本库的入库要求中，都包括了“代码编译通过”。这个阶段同时需要提交《程序配置清单》，为了同行评审的方便，有时还需要在每个代码文件的属性中标明，是新建的文件还是修改的文件。
4．代码的同行评审
这是CMM的要求，按照PR（同行评审）的流程规范进行，并且修改故障和提交评审报告，以及故障记录。同行评审一般不需要循环进行，除非代码质量很差，一次评审不能按照要求通过。
代码经过同行评审，即可进入调试阶段。
5．流程输出
编码阶段的输出，除了代码直接用于调试之外，还有很多的评审报告、记录报告，主要用于项目回顾。
文档是珠，操作为线，连贯成流程，制定完善的流程规范是让研发规范化的 步，认真地按照其进行操作，才是研发规范真正起到作用的关键。老板们如果担心自己的公司下班后不那么值钱，与其一门心思担心员工频繁跳槽，不如一边分析员工不稳定的原因，一边花些精力好好研究一下如何规范化研发操作，才能双管齐下，稳操胜券。
文章来源于领测软件测试网 https://www.ltesting.net/
