代码评审在软件项目管理中是经常组织的活动，通过代码评审的工作也确实给我们的团队带来很多的益处，简单谈谈代码评审的感受，你们的团队是否也在进行代码评审(Code Review)的相关工作呢？
1.为什么要组织代码评审
组织代码评审其主要目的是保障我们的代码质量和软件产品质量，其次是团队的学习提高，共同的成长。可以是两个方面的驱动，外在现实中的工作痛点和团队内在战斗力提高的驱动。
(1).实际工作中的痛点：
<1>.团队开发的软件质量越来越差，Bug居高不下，问题层出不穷；
<2>.团队的代码实现对应的业务功能，但却漏洞百出，业务实现的合理性，程序逻辑的严密性，考虑不周；
<3>.团队的代码风格各异，同一逻辑的代码结构，不同的人实现，其写法各异，风格不统一，重复造轮子；
<4>.团队的代码的维护性差、可读性差、可重用性差、灵活性很差，使开发人员开发滞后，运维人员修复Bug很是困扰；
<5>.团队代码中存在潜在的高危Bug(性能问题代码)，一般不会出问题，出现问题也不易排查，严重阻塞业务数据的流转；
<6>.开发团队交付的代码质量差，给测试团队带来很多的时间的浪费，低效率操作，使开发团队和测试团队陷入疲惫状态。
(2).团队内在驱动：
<1>.营造团队学习氛围。通过代码评审，团队成员彼此之间学习提高，如何才能写出更高效、更易扩展、更易维护的代码；
<2>.促进团队沟通交流。通过代码评审，团队可以有一个很好的沟通交流机会，提升沟通表达能力，提高团队凝聚力；
<3>.促进团队成长提高。通过代码评审，团队的整体战斗力都得到提高，不断的迭代强化下，团队可以交付高品质的软件产品。
正是基于工作中的痛点和团队内在的驱动，团队才组织代码评审，旨在提高软件质量和团队战斗力。
通过代码评审，由一行行高性能代码，一个个优良方法，一个个高内聚低耦合模块，一个个层次抽离的业务，整个系统质量的提升，由小积大，不断的持续改进，让我们的编码规范成为一种编程习惯。
通过代码评审事项的组织，团队成员的编码水平不断提高，在平时的代码中就可以规避掉一些很基本的错误，减少Bug的产生，同时不断的优化我们的代码，团队中每一个成员都得到提高，可能在其中你是学习者，可能在其中你是辅导者、引导者，都将是对个人和团队能力的提高。
2.代码评审事项评价
(1).好的地方：(正是解决上面提高的痛点和内在驱动)
<1>.代码评审，可以发现潜在的问题，做到风险提前控制；
<2>.代码评审，可以统一编码风格，促使团队形成良好的编码习惯；
<3>.代码评审，促进团队沟通交流、互相学习、改善团队氛围、提高团队凝聚力；
<1>.代码评审，可以发现潜在的问题，做到风险提前控制；
<2>.代码评审，可以统一编码风格，促使团队形成良好的编码习惯；
<3>.代码评审，促进团队沟通交流、互相学习、改善团队氛围、提高团队凝聚力；
<4>.代码评审，对于提升个人能力和团队能力有很大的帮助，使团队战斗力提高；
<5>.代码评审，可以节省开发和维护成本(易读、可维护、可扩展的代码)、测试成本(代码交付质量高)。
<5>.代码评审，可以节省开发和维护成本(易读、可维护、可扩展的代码)、测试成本(代码交付质量高)。
(2).不好的地方：
<1>.代码评审，暂用团队太多时间，过多的讨论问题细节，影响正常工作的进行且发现没有成效；
<2>.代码评审，不是为了提升代码质量、软件质量的目的，而是变成了相关指责、挑剔对方写的代码；
<3>.代码评审，审查会议团队很活跃，审查会议后没有跟踪记录，没有可供数据分析的记录，没有提炼性的产出。
<4>.代码评审，浮于形式，没有任何的奖惩机制做支撑，做好做坏都一样，不能提高团队整体实力和交付软件的质量。
3.代码评审注意事项
针对代码评审中存在不好的地方，为了很好的组织代码评审，让团队的代码评审工作真的见成效，需要注意以下事项：
(1).做好时间把控
代码评审必须做好时间把控，一是为了保证我们的会议高效性，一是为了不影响团队的其他工作的进行，一般控制在30-60分钟。
对于代码评审中的争议问题，短时间内不能给出好方案的，由会议纪要人记录下来，待会议后相关人员讨论，形成方案下次会议宣贯大家。
(2).调整团队心态
宣贯告知团队，组织代码评审的目的和意义，让团队成员摆正心态，具有良好的包容氛围、虚心学习请教的氛围。
团队帮你改进代码，帮你优化你的程序和代码写法，使你提高应该感激；作为问题提出者，能很好的正确引导同事也是个人能力的提高；作为活动的参与者，在审查他人代码的同时，既是一个自我检视的过程也是一个学习提高的过程。
(3).做好会议纪要
为了让我们的活动更好的执行下去，需要做好相关事项的纪要。由代码评审会议的纪要人，将审查会议上被审查人的发现的不符合团队代码规范的地方进行记录，以及在审查会议中有争议的问题进行记录，供以后进行下次代码评审会议的跟踪和以后数据分析的评级。
对于代码评审出的问题，具有团队同性的问题和解决方案，可以整理出来添加到团队的代码规范中，一点点积累规避基础性的问题。
(4).良好奖惩措施
为了更好调动团队积极性和代码评审的成效性，这个可选的原则是，建立良好的奖惩措施。
对于在评审会议评审出的有问题的代码，在下次评审会议时，检视其未做修改或在新的评审中原来的问题还是出现，给予记过，进行小小的惩罚；对于在评审会议积极发现问题代码和提供建议比较多的团队成员，给予奖励，累计一迭代周期后，根据每个人的记佳最多的，进行小小的奖励。
4.代码评审方案执行
代码评审主要是提高交付软件的软件质量和提升团队战斗力，其具体的方案也不拘一格，可根据团队的具体情况制定一个适合本团队的代码评审方案。
不要让代码评审变成团队工作的负担，不要变成阻碍团队做事的屏障，不要让代码评审达不到预期的成效，反而低效率运作，这些都是团队所不需要，如果真的是这种状态团队就需要好好检视一下，是我们没有采用正确的方式来组织代码评审，还是确实代码评审不适合对团队的成长，估计是我们的代码评审的方式方法不对占很大成份，那就要思考如何让代码评审工作达到甚至超过预期的效果。
(1).代码评审规范文档
要进行代码评审的工作，必须要有一个审核的指标和标准，代码规范算是其中之一。代码规范，是团队接受的、认可的、持续改进优化的，是团队都遵守的执行的标准。代码规范可以使团队代码的风格更加统一，可以规避掉一些常见的问题。
要进行代码评审的工作，必须要有一个审核的指标和标准，代码规范算是其中之一。代码规范，是团队接受的、认可的、持续改进优化的，是团队都遵守的执行的标准。代码规范可以使团队代码的风格更加统一，可以规避掉一些常见的问题。
如果在评审会议中对某些问题有争议，可参照标准来做衡量，减少不必要的争论，浪费时间；
如果代码规范的标准不合理，听取建议，确实认定不合理，及时改进，知会团队相关人员；
如果代码规范中并未提及的相关标准未，及时追加到代码规范，让代码规范标准更丰富。
如果现在有一份还算不错的代码规范，那就应用与团队，在不断的代码评审会议中，发现共性的问题，添枝加叶，不断的丰富起来；
如果现在还没有一份合格的代码规范，可以让团队成员，每个人提供4-5个代码规范的标准写到报事贴上，填录完毕将建议信息收集整理进行汇总分类，团队根据分类后的数据，讨论某一点是否可以加入我们的代码规范(或是借鉴他人的代码规范，把适合本企业的代码规范相关点整理到代码规范中)。
代码规范标准，不断的迭代丰富起来，我们的代码规范越来越能规避各种潜行的小问题，一些常规Bug和难以理解、难以维护的代码将在每个人的改进中，逐步减少，代码质量，产品质量也得到提高，团队整体水平也能到提高，团队的战斗力得到提高。
(2).代码评审组织形式
<1>.确定审查周期
为保证团队的高效和代码评审确实可以为我们的产品质量提高带来的意义，建议代码评审执行周期为一周，具体在一周的某一天某个时间段，团队可自行协商，可以逐步调整时间，确实保证代码评审的高效性，不要有太多的阻碍的因素和多任务处理并行，不要总是调整就好。
<2>.确定参与人员
老大参与：为确保初次审查活动的带动性，老大参与还是必须的，显示对于这项工作的重视。
项目组成员参与：建议没有紧急任务处理的团队成员都可以参与，这是一个大家沟通交流学习提高的过程。
指定审查会议主持人：主要是根据被审查人提交的相关代码和脚本进行整理，控制审查会议的时间和效率。
指定审查会议纪要人：主要是针对审查会议中的被审查人需要改进的代码问题、团队疑问质疑点、可提炼的共性规则进行纪要。
如果是团队多项目小组任务并行的话，可以分别小组内部组织也可以团队成员一起，参与成员也不要太多，效果不是很明显，小组多的话，小组间可以相互学习和参照对比。
<3>.确定审查内容
一周一迭代的代码评审的审查内容是：审查周期内提交的相关代码和数据库脚本。
一周一迭代的代码评审的审查内容是：审查周期内提交的相关代码和数据库脚本。
主要审查其代码和数据库脚本，有无违犯代码规范和需改进地方，有无明显的业务漏洞、逻辑漏洞以及是否存在性能问题。
其中本次代码评审要审查的总代码数和总存储过程数，以及审查的总人员数，可根据团队具体的情况和会议的时间来控制。
<4>.确定审查形式
<4>.确定审查形式
A.审查会议前，通知相关参与人，指定主持人和纪要人，被审查人提交审查相关代码和数据脚本。
其中主持人和纪要人，可以由团队成员轮值(提高团队参与积极性)，也可固定安排由某人来处理。
B.由主持人就这次会议做简要概述，然后后被审查展示讲解自己的代码，简要概述这段代码的功能，团队一起审查提交人代码。
主持人概述：团队第几次代码评审，本次被审查人是哪几个，审查的代码数和脚本数，上次遗留疑问解决宣贯，上次审查的执行确认。
被审查人概述：这个段代码的功能，代码的层次关系，对团队成员有疑问的业务和技术写法问题，做阐明讲解。
C.针对被审查人存在的问题做讨论，确定是否有问题，并由会议纪要人做相关内容的纪要。
纪要人主要纪要：代码和脚本的编写跟团队代码规范、有问题的业务漏洞和逻辑漏洞以及存在性能问题、争议无解的问题。
D.主持人引导被审查人的相关审查的推进，最后汇总此次代码评审审查人数，每个人的审查出的问题数，总问题数，做好纪要。
<5>.确定奖惩措施
为提高参与度和代码评审的成效，制定代码评审的奖惩制度，可由团队成员大家协商确定，要执行哪些惩罚和奖励。团队达成一致，团队认可，共同遵守。
为提高参与度和代码评审的成效，制定代码评审的奖惩制度，可由团队成员大家协商确定，要执行哪些惩罚和奖励。团队达成一致，团队认可，共同遵守。
越多越好，越好玩越好，越有意思越好，大家积极参与提供建议。可以是物质的，可以是娱乐性的建议。
针对提出需要改进，未做改进的小小惩罚一下，娱乐一下；针对累计代码评审周期，问题较少的，给与奖励；为团队其他成员代码指出代码问题比较多的，提供问题指导的，给予奖励。
针对提出需要改进，未做改进的小小惩罚一下，娱乐一下；针对累计代码评审周期，问题较少的，给与奖励；为团队其他成员代码指出代码问题比较多的，提供问题指导的，给予奖励。
（如：一次代码评审每人25分，一个月汇总一次，惩罚在每次审查时进行，奖励在汇总时进行，惩罚给大家卖水果、唱一首歌、表演个节目等等）
5.代码评审成效
代码评审工作不需要我们一次做的很到位，必须要做到ABC等等，重在逐步的改善，有所成效的提高。
代码评审工作执行一定周期后，需要我们检视一下代码评审工作是否真的可以促进我们的代码质量和产品质量，团队表决。
需要思考问题以及问题相关数据：
(1).代码评审工作对我们的目的有没有推进作用？
(2).代码评审工作对我们的Bug的减少有没有推动作用？
(3).代码评审工作对我们的代码不规范的地方在审查中越来越少？
(4).代码评审工作对我们的团队整体的战斗力有没有促进作用？
(5).代码评审工作对团队中每个人都有提高？团队中每个人的感受也是不一样的？