代码审查(Code Review)
一、概述
代码审查（Code Review)是软件开发中常用的手段，和QA测试相比，它更容易发现和架构以及时序相关等较难发现的问题，还可以帮助团队成员提高编程技能，统一编程风格等，目前监控团队虽然提倡代码审查，也有相关的辅助工具，但是一直没有真正的推行起来，这半年的时间里，一些线上的bug如果经过代码审查，基本上可以避免的，大家也逐渐认识到代码审查可以有效地提高代码质量。
二、代码审查的作用
1、提高代码质量。
通过代码审查来发现bug及代码中的不规范，这是不容置疑的，通过代码审查，代码将更加整洁，有更好的注释，更好的程序结构。
2、提高开发者开发水平。
开发者知道自己编写的代码会被同事审查，将会更加认真的编写代码，也将会督促开者不断地学习、向有经验的同事请教。
3、提高程序的可维护性。
一份程序代码将会有更多的同事熟悉，更好的代码质量，自
然地也增加程序的可维护性。
4、提高开发者的对编码的责任感。
如果你在编程，而且知道将会有同事检查你的代码，你编程态度就完全不一样了。你写出的代码将更加整洁，有更好的注释，更好的程序结构——因为你知道，那个你很在意的人将会查看你的程序。没有代码审查，你知道人们最终还是会看你的程序。但这种事情不是立即发生的事，它不会给你带来同等的紧迫感，它不会给你相同的个人评判的那种感受。
5、传播知识
在很多的开发团队里，经常每一个人负责一个核心模块，每个人都只关注他自己的那个模块。除非是同事的模块影响了自己的程序，他们从不相互交流。这种情况的后果是，每个模块只有一个人熟悉里面的代码。如果这个人休假或——但愿不是——辞职了，其他人则束手无策。通过代码审查，至少会有两个人熟悉这些程序——作者，以及审查者。审查者并不能像程序的作者一样对程序十分了解——但他会熟悉程序的设计和架构，这是极其重要的。
三、代码审查的执行障碍
1、缺少代码审查的标准
缺少代码审查的标准，往往审查人员习惯性地根据自身开发经验去进行代码审查，容易变成去挑毛病，找bug，容易产生
不良地影响。
2、资深开发人员的较少，工作过多，缺少代码审查的时间安排
在一个小规模团队里，资深的同事总是忙不过来，因为核心的工作都在等着他做，资深的开发人员少，代码审查的质量自然上不去。
3、团队成员的技术差距过大
一个团队中往往有不少经验较浅的开发人员，当然编码水平也就相对较差，如果缺少有效的激励手段，往往资深的开发人员是比较讨厌经常去审查经验很浅的开发人员的代码。
四、代码审查的实践要素。
虽然代码审查是一个被广泛采纳的实践，但是由于存在很多的实践方式，所以开发团队经常搞不清楚它的最佳实践是什么样的，正确的代码审查应该重点考虑的几个因素有以下几点。
1、人员结构
在你的团队中有多少同事拥有足够的专业技能来担当合格的代码审查者？作者曾经和多个开发团队沟通过，这些团队都声称本身只有一个资深的开发人员，如果让他来负责所有的代码审查工作，那么团队的核心开发就无法开展了。作者也遇到过类似的情况。在一个小规模团队里，资深的同事总是忙不过来，因为核心的工作都在等着他做。
2、地理位置
你的团队成员是如何分布的？他们是否是分散在世界各地还是坐在同一个敞亮的办公室里？代码审查需要精力的专注和反馈，如果开发人员能够面对面的沟通，那么审查工作会便于实施。而物理隔离的远程团队很难达到代码审查的满意结果。3、所在领域
你所在的IT领域需要遵守怎样的规则和约束呢？如果你在一个受到严格监管的行业，那么你必须遵循有关审计和报告的规则，这意味着你必须想办法跟踪代码审查的频率和质量。如果所在的领域把安全性作为重点，那么可能在代码审查过程中要引入安全审计。
4、复杂性
你的代码复杂性如何？在代码审查时，需要多个不同专业技能的审查者吗？例如，游戏开发可能会引入非常复杂的业务逻辑来处理文字交互和场景跟踪，同时还需要特定的动画处理和内存管理技术。在审查如此复杂的代码时，应该引入多个审查者从不同角度来检阅代码的质量。
而且在许多情况下，不同的项目有不同的需求——存在多个团队构建应用，需要不同的配置文件。这里有一些技巧可以帮助你改进代码审查过程的工具并解决一些可能会面临的问题：A.促进沟通
任何审查过程，不论是代码还是文档还是绩效，最好是面对面进行。在你使用工具做完代码审查之后，与相应的开发人员约个时间做口头的反馈。如果你们不在同一地区，可以利用视频或者电话来进行沟通，但是这种沟通是必要的，你可以以此作为协作和指导的一种手段。
B.利用专业技能
如果被审查的代码与其他代码领域存在关联，或者对安全、性能、可扩展性等方面存在一定的影响，你可能无法只安排一个人来完成审查工作。你需要多个人来查看代码以确保所有可能的后果都被考虑在内。在这种情况下，最好找到一个工具来协助多个人完成审查工作。该工具的作用包括指定哪个人审查哪个角度并把相应的代码展现出来，而且还可以保存审查人员的注解。
C. 公开审查意见
审查工具的优点之一是多人可以集中地审查相同的代码。把所有人叫到一个屋子里做团队审查非常不利于大家考虑各个不同的方面。但是工具可以帮助你让大家分别查看代码并把所有的意见集中起来：
?避免意见重复，如果别人已经发表了类似的看法，那么后面的人就不用记录了。
?团队学习，通过查看别人的意见能够学习其他人的思维角度和专业领域。
监督审查过程。
五、代码审查的一些常用经验与注意事项。
1.代码审查要求团队有良好的文化
团队需要认识到代码审查是为了提高整个团队的能力，而不是针对个体设置的检查“关卡”。
“A的代码有个bug被B发现，所以A能力不行，B能力更好”，这一类的陷阱很容易被扩散从而影响团队内部的协作，因此需要避免。
另外，代码审查本身可以提高开发者的能力，让其从自身犯过的错误中学习，从他人的思路中学习。如果开发者对这个流程有抵触或者反感，这个目的就达不到。
2.谨慎的使用审查中问题的发现率作为考评标准在代码审查中如果发现问题，对于问题的发现者来说这是好事，应该予以鼓励。但对于被发现者，我们不主张使用这个方式予以惩罚。软件开发中bug在所难免，过度苛求本身有悖常理。更糟的是，如果造成参与者怕承担责任，不愿意在审查中指出问题，代码审查就没有任何的价值和意义。
3.控制每次审查的代码数量根据smartbear在思科所作的调查，每次审查200行-400行的代码效果最好。每次试图审查的代码过多，发现问题的能力就会下降，
我们在实践中发现，随着开发平台和开发语言的不同，最优的代码审查量有所不同。但是限制每次审查的数量确实非常必要，因为这个过程是高强度的脑力密集型活动。时间一长，代码在审查者眼里只是字母，无任何逻辑联系，自然不会有太多的产出。
4.带着问题去进行审查我们在每次代码审查中，要求审查者利用自身的经验先思考可能会碰到的问题，然后通过审查工作验证这些问题是否已经解决。一个窍门是，从用户可见的功能出发，假设一个比较复杂的使用场景，在代码阅读中验证这个使用场景是否能够正确工作。
使用这个技巧，可以让审查者有代入感，真正的沉浸入代码中，提高效率。大家都知道看武侠小说不容易瞌睡，而看专业书容易瞌睡，原因就是武侠小说更容易产生代入感。
有的研究建议每次树立目标，控制单位时间内审核的代码数量。这个方法在我们的实践中显得很机械和流程化，不如上面的方法效果好。
5.所有的问题和修改，必须由原作者进行确认如果在审查中发现问题，务必由原作者进行确认。
这样做有两个目的：
(1)确认问题确实存在，保证问题被解决
(2)让原作者了解问题和不足，帮助其成长
有些时候为了追求效率，有经验的审查者更倾向于直接修改代码乃至重构所有代码，但这样不利于提高团队效率，并且会增加因为重构引入新bug的几率，通常情况下我们不予鼓励。
6.利用代码审查激活个体“能动性" 即使项目进度比较紧张，无法完全的进行代码审查，至少也要进行部分代码的审查，此时随即抽取一些关键部分是个不错的办法。
背后的逻辑是，软件开发是非常有创造性的工作，开发者都有强烈的自我驱动性和自我实现的要求。让开发者知道他写的任何代码都可能被其他人阅读和审察，可以促使开发者集中注意力，尤其是避免将质量糟糕，乃至有低级错误的代码提交给同伴审查。开源软件也很好的利用了这种心态来提高代码质量。
7.在非正式，轻松的环境下进行代码审查如前所述，代码审查是一个脑力密集型的工作。参与者需要在比较轻松的环境下进行该工作。因此，我们认为像某些实践中建议的那样，以会议的形式进行代码审查效果并不好，不仅因为长时间的会议容易让效率低下，更因为会议上可能出现的争议和思考不利于进行如此复杂的工作。
8.提交代码前自我审查，添加对代码的说明所有团队成员在提交代码给其他成员审查前，必须先进行一次审查。这次自我修正形式的审查除了检查代码的正确性以外，还可以完成如下的工作：
(1)对代码添加注释，说明本次修改背后的原因，方便其他人
进行审查。
(2)修正编码风格，尤其是一些关键数据结构和方法的命名，提高代码的可读性。
(3)从全局审视设计，是否完整的考虑了所有情景。在实现之前做的设计如果存在考虑不周的情况，这个阶段可以很好的进行补救。
我们在实践中发现，即使只有原作者进行代码审查，仍然可以很好的提高代码质量。
9.实现中记录笔记可以很好的提高问题发现率成员在编码的时候应做随手记录，包括在代码中用注释的方式表示，或者记录简单的个人文档，这样做有几个好处：
(1)避免遗漏。在编码时将考虑到的任何问题都记录下来，在审查阶段再次检查这些问题都确认解决。
(2)根据研究，每个人都习惯犯一些重复性的错误。这类问题在编码是记录下来，可以在审查的时候用作检查的依据。
(3)在反复记录笔记并在审查中发现类似的问题后，该类问题出现率会显著下降
10.使用好的工具进行轻量级的代码审查比如利用findbug 进行代码扫描。
六、实现代码审查的前提条件
（一）、审查制度的执行前提
1、代码审查必须是基本制度，是工作中一部分。
2、在团队中需要有一份大家接受的代码规范文档。
3、与业务需求相关的代码修改，需要审查代码的同事熟悉业务需求，参与设计评审，不熟悉需求是不能有效地审查代码。
4、代码审查是工作中的一部分，需要安排一定的时间来进行，这需要领导在工作安排中合理安排时间。
（二）、代码审查的执行前提
1、Code Review人员是否理解了Code Review的概念和Code Review将做什么
如果做Code Review的人员不能理解Code Review对项目成败和代码质量的重要程度，他们的做法可能就会是应付了事。2、代码是否已经正确的build，build的目的使得代码已经不存在基本语法错误
我们总不希望高级开发人员或是主管将时间浪费在检查连编译都通不过的代码上吧。
3、代码执行时功能是否正确
Code Review人员也不负责检查代码的功能是否正确，也就是说，需要复查的代码必须由开发人员或质量人员负责该代码的功能的正确性。
4、Review人员是否理解了代码
做复查的人员需要对该代码有一个基本的了解，其功能是什么，是拿一方面的代码，涉及到数据库或是通讯，这样才能采取针对性的检查
5、开发人员是否对代码做了单元测试
这一点也是为了保证Code Review前一些语法和功能问题已经得到解决，Code Review人员可以将精力集中在代码的质量上。
七、代码审查需要做什么
Code Review主要检查代码中是否存在以下方面问题：代码的一致性、编码风格、代码的安全问题、代码冗余、是否正确设计以满足需求（性能、功能）等等
1完整性检查
代码是否完全实现了设计文档中提出的功能需求
代码是否已按照设计文档进行了集成和Debug
代码是否已创建了需要的数据库，包括正确的初始化数据
代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型
2 一致性检查
代码的逻辑是否符合设计文档
代码中使用的格式、符号、结构等风格是否保持一致
3 正确性检查
代码是否符合制定的标准
所有的变量都被正确定义和使用
所有的注释都是准确的
所有的程序调用都使用了正确的参数个数
4 可修改性检查
代码涉及到的常量是否易于修改(如使用配置、定义为类常量、使用专门的常量类等)
代码中是否包含了交叉说明或数据字典，以描述程序是如何对变量和常量进行访问的
代码是否只有一个出口和一个入口（严重的异常处理除外）
5 可预测性检查
代码所用的开发语言是否具有定义良好的语法和语义
是否代码避免了依赖于开发语言缺省提供的功能
代码是否无意中陷入了死循环
代码是否是否避免了无穷递归
6 健壮性检查
代码是否采取措施避免运行时错误（如数组边界溢出、被零除、值越界、堆栈溢出等）
7 结构性检查
程序的每个功能是否都作为一个可辩识的代码块存在
循环是否只有一个入口
8 可追溯性检查
代码是否对每个程序进行了唯一标识
是否有一个交叉引用的框架可以用来在代码和开发文档之间相互对应
代码是否包括一个修订历史记录，记录中对代码的修改和原因都有记录
是否所有的安全功能都有标识
9 可理解性检查
注释是否足够清晰的描述每个子程序
是否使用到不明确或不必要的复杂代码，它们是否被清楚的注释使用一些统一的格式化技巧（如缩进、空白等）用来增强代码的清晰度
是否在定义命名规则时采用了便于记忆，反映类型等方法
每个变量都定义了合法的取值范围
代码中的算法是否符合开发文档中描述的数学模型
10可验证性检查
代码中的实现技术是否便于测试
八、代码审查的流程。
1、在开发之前就需要确认谁来进行代码审查，单个还是多个审查人，确定代码审查的方式（review board，面谈讨论沟通）。
2、确定好审查人后需要让相应的审查人员参与熟悉开发的功能需求（业务需求、性能需求）是什么，以便让审查人知道需要审查的代码实现的功能包含那些要点，在实际的工作中以需求讨论、设计评审来完成审查人员对需求与设计的熟悉。
3、开发完成后提交到review board中通知代码审查人进行代码审查，代码审查人如果发现有需要代码中有需要修改的地方，在review board中写下原因反馈给开发人员，开发人员按要求进行代码修改后再度提交到review board，继续进行代码审查，直至审查通过。
代码审查报告 xxxx公司
版本信息
致？其余单词首字母大写的命名方式， 禁止使用下划线(_)数字等方式命名 不要出现局部变量，成员变量大写字母开头等问题 一般是否遵循了最小长度最多信息原则？各种命名尽可能短，表意准确，除2代替…to?，4代替…for?外，不建议使用数字在命名中 重要has/can/is前缀的函数是否返回布尔 型？ 成员变量，方法参数，局部变量等为布尔型时， 如果出现has/can/is开头，则将这些词去掉 重要类名是否存在重名问题？自己实现的类尽量不要和别人的类重名， 尽管不在同一个包下，特别是子类和父类重名的情况 注释 重要注释是否较清晰且必要？方法JAVADOC注释中需要说明各参数、返回值 及异常说明，参数说明需按照参数名称及用意对应标注 重要复杂的分支流程是否已经被注释？一般距离较远的}是否已经被注释？ 重要函数是否已经有文档注释？（功能、输 入、返回及其他可选） 文件，类（含接口，枚举等），成员变量， 方法前需要有JAVADOC的注释 一般特殊用法是否被注释？ 声 明、 空 白、 缩 进 一般每行是否只声明了一个变量？（特别是那些可能出错的类型） 重要变量是否已经在定义的同时初始化？ 重要类属性是否都执行了初始化？ 一般代码段落是否被合适地以空行分隔？ 一般是否合理地使用了空格使程序更清晰？基本代码格式中的空格符不可缺少，
这些空格出现在?,:,+,-,*,/,=,==,>,<,>=,<=,!=, 及各种括号附近 提示代码行长度是否在要求之内？每行不得超过120个字符 重要controller，service, dao 中不要声明有 状态的变量。 此变量不能被修改。如果要进行修改， 必须通过锁进行控制。 一般折行是否恰当？ 一般集合是否被定义为泛型类型？定义集合时，建议定义其泛型类型，减少类型转换和警告错误 语句/功能分布/规模 一般包含复合语句的{}是否成对出现并符合规范？ 重要是否给单个的循环、条件语句也加了 {}？ if,else,else if,while,for,case等 代码块必须用{}包围 一般单个变量是否只做单个用途？ 重要单行是否只有单个功能？（不要使用；进行多行合并） 重要单个函数是否执行了单个功能并与其命名相符？ 一般操作符＋＋和——操作符的应用是否符合规范？ 规模 重要单个函数不超过规定行数？ 重要缩进层数是否不超过规定？ 可靠 性 （总
代码走查(code walkthrough)和代码审查(code inspection)是两种不同的代码评审方法, 代码审查是一种正式的评审活动，而代码走查的讨论过程是非正式的。 最近对项目组进行代码评审，发觉需要对代码评审中找到的问题进行一下分类，大概可以分成以下几类问题： 1. Comment 注释没写，或者格式不对，或者毫无意义 2. Coding Standard 没遵守代码规范 3. Existing Wheel 重复现成的代码，或者是开源项目，或者公司已有代码 4. Better practice Java或者开源项目，有更好的写法 5. Performance bottle and Improvement 性能瓶颈和提高 6. Code Logic Error 代码逻辑错误 7. Business Logic Error 业务逻辑错误 代码审查列出问题的类型，并有解决情况报告 11月23日 代码走查——项目走向成功的锦囊之一 说起代码走查，相信每个人都不陌生，但为什么要执行代码走查，什么时候来执行代码走查，如何有效执行代码走查，很多人的看法和见解都不一样。 一般的看法，认为代码走查是一种非正式的代码评审技术，它通常在编码完成之后由代码的作者向一组同事来讲解他自己编写的代码，由同事来给出意见。 这种做法在很多做软件开发组织中经常采用。但从实际执行效果来看，成效并不都那么明显，反而很多组织的这种做法有浪费时间之嫌。主要是因为代码走查活动时间有限，而参加代码走查的人之前没有较多的时间来提前了解被走查的代码，故而在实际执行时能被走查的代码所占的比例并不高，同时也发现不了多少本质问题。 随着软件外包业的发展，它有别于软件产品开发，客户对于产品的要求不再局限于系统是否能够正确运行。而是在设计、代码的品质上也有了更多的要求。有的客户甚至会在我们每次交付后先来检查我们的代码品质，只要是代码不符合要求就会被拒绝。
1. Code Revie进行检查试过现的质量保机制，通这个机制我可以代码、注一种Code Revie来确认方案计和代码的要用在软件工程程中改进码质量，Code Revie以达到如下Code Review代码审查规范1. Code Review目的 Code Review是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们可以对代码、测试过程和注释进行检查。 Code Review主要用来在软件工程过程中改进代码质量，通过Code Review可以达到如下目的： 在项目早期就能够发现代码中的BUG。?帮助初级开发人员学习高级开发人员的经验，达到知识共享。?避免开发人员犯一些很常见，很普通的错误。?保证项目组人员的良好沟通。?项目或产品的代码更容易维护。? 2. Code Review的前提条件 代码提交审核前，开发者必须确保代码符合如下条件，审核者需要确保所有前提条件都已满足方可开始审查，同时也是审查的主要检查点。 所有代码注释清晰，语法正确，编译通过。?日志代码完整，业务日志、系统日志分开，中文描述，脱敏处理，状态变更，?全部清晰明确。 测试代码覆盖全部分支和流程，暂时统一使用工具Emma（各编译器可下载对?应插件）进行Coverage Check。 项目引用关系明确，依赖关系清晰，配置文件描述。? 的审查范围3. Code Review 代码的一致性、编码风格、代码的安全问题、脱敏问题、代码冗余、是否正确设计以符合设计要求（性能、功能）与设计文档相同等等。）完整性检查（Completeness3.1、 代码是否完全实现了设计文档中所涉及的所有流程和功能点?代码是否已包含所有所需的业务日志、系统日志、异常日志，日志内容是否完?整，日志文件配置是否正确。 代码是否使用缓存等，配置信息是否正确可配置。?代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型等?一致性检查（Consistency）3.2、 代码的逻辑是否符合设计文档?代码中使用的格式、符号、结构等风格是否保持一致?）Correctness3.3、正确性检查（代码是否符合制定的标准?所有的变量都被正确定义和使用?所有的注释都是准确的?所有的程序调用都使用了正确的参数个数? Modifiability）、3.4 可修改性检查（如使用配置、定义为类常量、使用专门的常量代码涉及到的常量是否易于修改(?)类等 代码中是否包含了交叉说明或数据字典，以描述程序是如何对变量和常量进行?访问的 代码是否只有一个出口和一个入口（严重的异常处理除外）?）可预测性检查（Predictability3.5、代码所用的开发语言是否具有定义良好的语法和语义?是否代码避免了依赖于开发语言缺省提供的功能?代码是否无意中陷入了死循环?代码是否避免了无穷递归?．
程序开发部代码审查制度 1.文档目的 (1) 2.适用范围 (1) 3.工作制度 (1) 3.1代码审查范围 (1) 3.2代码审查标准 (1) 3.2.1所开发的代码功能是否与详细设计文档中描述的保持一致。 (1) 3.2.2代码是否符合编码规范 (1) 3.2.3代码是否正确无误，没有隐含的错误。 (1) 3.3审查执行流程 (1) 3.4代码审查活动的监督 (2) 1.文档目的 该文档的阅读者主要为部门总监、部门经理、开发组长和程序员。通过该制度来规范代码编写，从而提高代码质量。 2.适用范围 该制度适用于程序开发部部门内部。 3.工作制度 3.1代码审查范围 审查任务目标包含的所有类。 3.2代码审查标准 3.2.1所开发的代码功能是否与详细设计文档中描述的保持一致。 此项检查设计部门会做抽查，开发部门需要做为重点执行项，保证代码和设计的一致性。3.2.2代码是否符合编码规范 此项检查作为开发部重点执行项，必须和编码规范保持一致。 3.2.3代码是否正确无误，没有隐含的错误。 此项检查要保证在组件功能无误的基础上进行，需要有经验的高级程序员对具体程序片段进行检查，纠正逻辑不合理代码、垃圾代码等。此工作在现阶段可以做为次要执行项。 3.3审查执行流程 1．检查的粒度――功能组件
2．当程序员开发完成一个组件，并且告知组长可以进行审查时，由开发组长或者指定的高级程序员来做审查工作。 3．审查人必须详细检查目标的代码编写，并且需要填写《代码审查表》。 4．如果审查未能通过，被审查人按照《代码审查表》的审查意见进行修改。 5．重复执行步骤2-4，直到审查通过。 3.4代码审查活动的监督 代码审查制度为代码质量的绩效考核提供参考，作为绩效考核代码质量评分的依据。
英文原文：oschina 代码审查可以帮助提高代码质量，避免由于代码习惯而造成的 bug。下面列出的这些要点因该可以作为大部分代码审查的指导，如果是 Java 应用的话，这些建议应该被视作最佳实践。 文档 1. Javadoc 应该在每一个类和方法中添加。 2. 如果是修复某个 bug，应该添加 bug ID。 3. 走捷径的方法或者复杂的逻辑要有解释。 4. 如果代码会被公开，每个文件头都要标注版权信息。 5. 复杂的 HTML，JavaScript，CSS 应该包含文档。 功能 1. 如果类似的逻辑被使用了多次，应该把它写成一个帮助类，然后在多出调用。 2. 鼓励使用 API 而不是重复编写代码解决相同的问题。 3. 要强调代码的单元测试。 4. 任何新加的代码不应该破坏已有的代码。 5. 假如是 Web 应用，JSP 不应该包含 Java 代码。 安全 1. 任何代码都不能执行用户的输入，除非转义过了。这个常常包含 JavaScript 的 eval 函数和 SQL 语句。 2. 禁止那些在短时间内提交非常多请求的 IP。 3. 任何类，变量，还有方法都应该有正确的访问域。 4. 尽量避免使用 iframe。 性能 1. 所有数据库和文件操句柄在不需要的时候都应该被关闭。 2. SQL 语句的写法会导致性能千差万别。 3. 鼓励创建不可变（immutable）的类。 4. 类似的逻辑代码，尽量通过 if else 语句来实现更多的重用。 5. 尽量避免使用重对象（heavy objects）。 6. 如果是 Web 项目，请检查是否使用了合适的图片尺寸，CSS sprites 和浏览器缓存等技术。
WATER Corporation 代码走查计划书Version 2.0 XXX 2012/3/20
文档修改记录
目录 1.进度计划 (4) 2.待评审物 (4) 3.成员角色 (5) 4.基本原则 (5) 4.1代码评审原则 (5) 4.2评审指导文档 (6) 5.走查过程定义 (6) 5.1代码走查计划准备阶段 (6) 5.2个人代码走查阶段 (6) 5.3代码走查会议阶段 (7) 5.4缺陷修改与关闭 (7)
1.进度计划 小组代码走查活动时间进度安排如下所示： 2.待评审物 待评审物名称：银行系统取款模块源代码V1.0 （SC-Banking-Withdraw- V1.0） Figure 1 UML Model for Banking-Withdraw
3.成员角色 组长：制定代码走查的计划、安排代码走查活动职责分工、组织代码走查，确保代码走查的过程规范执行； 质量保证人员：制定CheckList，记录代码走查会议以及完成问题记录报告； 开发人员：完成代码，在代码走查中引领走查人员读代码，走查结束后并根据走查的问题记录报告完成代码修改； 评审人员：依据编程规范和CheckList执行代码走查，使用Jupiter工具记录发现的问题。 4.基本原则 4.1 代码评审原则 1.一次检查少于200～400行代码 2.努力达到一个合适的检查速度：每小时少于300～500行代码 3.有足够的时间、以适当的速度、仔细地检查，但不宜超过60～90分钟 4.在复审前，代码作者应该对代码进行注释 5.建立量化的目标并获得相关的指标数据，从而不断改进流程 6.使用检查表（checklist）肯定能改进双方（作者和复审者）的结果 7.验证缺陷是否真正被修复
代码审查规范 1. Code Review目的 Code Review是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们可以对代码、测试过程和注释进行检查。 Code Review主要用来在软件工程过程中改进代码质量，通过Code Review可以达到如下目的： ?在项目早期就能够发现代码中的BUG。 ?帮助初级开发人员学习高级开发人员的经验，达到知识共享。 ?避免开发人员犯一些很常见，很普通的错误。 ?保证项目组人员的良好沟通。 ?项目或产品的代码更容易维护。 2. Code Review的前提条件 代码提交审核前，开发者必须确保代码符合如下条件，审核者需要确保所有前提条件都已满足方可开始审查，同时也是审查的主要检查点。 ?所有代码注释清晰，语法正确，编译通过。 ?日志代码完整，业务日志、系统日志分开，中文描述，脱敏处理，状态变更，全部清晰明确。 ?测试代码覆盖全部分支和流程，暂时统一使用工具Emma（各编译器可下载对应插件）进行Coverage Check。 ?项目引用关系明确，依赖关系清晰，配置文件描述。 3. Code Review的审查范围 代码的一致性、编码风格、代码的安全问题、脱敏问题、代码冗余、是否正确设计以符合设计要求（性能、功能）与设计文档相同等等。
3.1、完整性检查（Completeness） ?代码是否完全实现了设计文档中所涉及的所有流程和功能点 ?代码是否已包含所有所需的业务日志、系统日志、异常日志，日志内容是否完整，日志文件配置是否正确。 ?代码是否使用缓存等，配置信息是否正确可配置。 ?代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型等 3.2、一致性检查（Consistency） ?代码的逻辑是否符合设计文档 ?代码中使用的格式、符号、结构等风格是否保持一致 3.3、正确性检查（Correctness） ?代码是否符合制定的标准 ?所有的变量都被正确定义和使用 ?所有的注释都是准确的 ?所有的程序调用都使用了正确的参数个数 3.4、可修改性检查（Modifiability） ?代码涉及到的常量是否易于修改(如使用配置、定义为类常量、使用专门的常量类等) ?代码中是否包含了交叉说明或数据字典，以描述程序是如何对变量和常量进行访问的 ?代码是否只有一个出口和一个入口（严重的异常处理除外） 3.5、可预测性检查（Predictability） ?代码所用的开发语言是否具有定义良好的语法和语义 ?是否代码避免了依赖于开发语言缺省提供的功能 ?代码是否无意中陷入了死循环 ?代码是否避免了无穷递归 3.6、健壮性检查（Robustness）
产品代码评审表 注：表头检查项目中黑体的项目表示必审项。
使用说明： 1.此表用于检查产品/项目代码的状况，从而从代码上对产品质量进行提高。 2.由产品经理或设计人员确定代码的检查范围，以核心业务处理的代码检查为主； 3.按照确定的检查范围列出需要检查的类清单，并通过检查代码得出评审结论，对于各种类的检查侧重点可以不同； 4.代码检查采用程序员自己检查和至少一个其他程序员进行复查的方式进行； 5.在代码实现的功能基本正确以后才能进行该部分代码的确认，对评审发现问题的代码要复查； 6.类型有以下几种状态：界面（UI）、业务处理（BO）、数据处理（DM）、数据对象（VO）； 7.按照检查项目逐项确认，对正确的项填写“Y”，有问题的项填写“N”，不需确认的项填写“－”，未确认的项不填； 8.评审结果可以分几种：A--好、B--合格、C--有问题、D--有严重问题。对于有问题和有严重问题的需要注明问题的内容（可以附加问题说明），对 于这种情况需要再重新进行代码修改并重新进行确认； 9.在代码提交时要求同时提交本确认表，提交时要保证所有检查的类的评审结果为A或B； 10.确认的项目除列出的项目外，产品组可以补充项目。项目说明： ●易读性：代码结构清晰； ●注释清晰：对功能的注释及代码的作者； ●命名规范：变量、类、方法、属性的命名符合公司开发规范； ●逻辑正确性：业务逻辑处理的正确性； ●事务一致性：TRANSACTION是否一致； ●Sql语句清晰：SQL语句结构是否清晰； ●计算精度：如计算精度有问题时是否使用了UFDouble； ●用标准控件：对于可以使用标准控件的是否使用标准控件； ●调用中间件：不存在反复调用中间件的情况； ●BS与UI交叉：没有BS类与UI类的交叉调用情况； 通过检查以上项目，根据情况得出评审的结论，必审项目要求必须检查；
综合征管信息系统 代码走查规范 文档编号： 当前版本： 1.0 修改日期：2010年8月18 日
一、JA V A编程规范 (3) 1、变量定义问题 (3) 2、变量命名规则 (3) 3、变量的声明和初始化(I NITIALIZATION) (3) 4、换行(W RAPPING L INES) (4) 5、M AP对象使用问题 (4) 6、EQUALS方法使用问题 (5) 7、IMPORT多余包问题 (5) 8、N ULL P OINTER E XCEPTION问题 (6) 9、关于对象声明问题 (7) 10、注释 (7) 11、访问静态变量或方法 (8) 12、使用静态变量 (8) 13、I F语句 (8) 14、J A V A源文件的长度 (8) 15、方法的长度 (8) 二、项目开发规范 (8) 1、J A V A文件命名规则 (8) 2、JSP代码规范 (9) 3、CTRL代码规范 (14) 4、E VENT &VO&BO (17) 5、P ROXY代码规范 (18) 6、日志 (20) 7、异常处理 (21) 8、缓存 (22)
一、J A V A编程规范 1、变量定义问题 如果定义的变量只是在某个局部内使用，就在局部内定义，不要在局部外定义。 问题代码： // 返回的明细信息放到vo里传到前台 MAmkdjVO mamkdjVO = new MAmkdjVO(); //如果找到详细信息的记录，就展现 if (responseEvent.getFindNoRecordFlag() == "1") { mamkdjVO = responseEvent.getDetailVO(); 更正代码：(mamkdjVO只是在if条件内使用，只需要自if内定义即可) //如果找到详细信息的记录，就展现 if (responseEvent.getFindNoRecordFlag() == "1") { // 返回的明细信息放到vo里传到前台 MAmkdjVO mamkdjVO = responseEvent.getDetailVO(); 2、变量命名规则 1、禁用差别不大（只有一个或少数几个字母不同）的名称 例如：hiThere和hiThre 2、在名称中禁用下划线字符('_') 3、变量的声明和初始化(Initialization) 1、避免声明的局部变量覆盖上一级声明的变量 2、尽量在声明局部变量的同时初始化。
代码评审制度 代码评审也叫代码复查、Code review，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。 评审的内容 编码规范问题–命名不规范、magic number、System.out……； 代码结构问题–重复代码、巨大的方法和类、分层不当、紧耦合； 工具、框架使用不当– 实现问题–错误验证、异常处理、事务划分、线程、性能、安全、实现过于复杂、代码可读性不佳、扩展性不好； 测试问题–可测试性不好、测试覆盖度不够。 代码评审不负责检查功能、逻辑是否正确，这些靠单元测试和QA工作来解决。 代码评审的好处 ●提高代码质量； ●在项目的早期发现缺陷，将损失降到最低； ●评审的过程也是重新梳理思路的过程，双方都加深了对系统的理解； ●促进团队沟通、促进知识共享、共同提高； 交叉评审——代码走查 交叉评审也就是团队成员互相检查代码。参与者可以是任意两个组员，或开发组长分别与每个组员结对进行。 评审时机在下班前半小时，对当天改动的模块进行评审。 代码作者讲解如何以及为何进行这样实现，评审者提出问题和建议。 每次评审需要做记录并保存到SourceSafe。 注意：每次评审不要贪多，当一次评审超过400行代码时，能发现的缺陷数显著降低——事倍功半。 会审 会审以项目为单位，召开专门的代码评审会议。参与者包括项目组全体成员，其他组的开发组长也应尽量参加。会审的时机选择在开发进行某一定阶段时，对共性问题进行总结，对好的做法进行提炼和推广。 会审之前需做好会前准备工作，组织者应通知各参与者本次评审的范围，参与者阅读代码，列出发现的问题、亮点，汇总给组织者。准备工作要细致，需要给出详细问题描述以及相关代码在SourceSafe上的地址等。 评审代码可以选择最近一次迭代开发的代码、系统关键模块、业务较复杂的模块或缺陷率较高的模块。 会议的议程，如果是第一次会议，先由改项目组长做整体介绍，参与者依次发言，结合
代码走查指导书 一、目的 1、根据需求、设计尽早发现在各个单元中存在的缺陷，从单元测试阶段抓质量； 2、依靠单元测试，执行代码走查，更快地掌握、了解需求、设计的变更，发现问题并 及时修改测试用例； 3、从另一方面去促使开发人员提高软件编码及单元测试的质量； 4、使测试人员更好地理解业务，掌握项目信息； 二、前提 测试人员需要深刻理解需求、理解设计； 三、测试环境 由测试leader负责搭建一个简易的测试环境，数据库最好与开发部公用； 注：单元测试的很多数据无法通过系统功能去制造，避免因数据的不规范而引发缺陷，所以尽量不要直接在数据库操作； 四、测试范围 1、设计的完整性；（根据提交的单元测试页面及实时变更记录测试） 2、业务的正确性；（根据项目的业务需求测试）（以1为测试前提） 3、功能的正确性；（根据详细设计测试）（以1、2为测试前提） 1）页面所有事件元素（增、删、改、查、上传等按钮、控件的操作）的测试； 2）页面初始状态的默认值测试； 3）设计要求的必输项测试； 4）系统统一设计风格的测试；（如清空查询条件的清空按钮） 5）边界数据的测试； 6）Html源码的测试； 7）接口测试；（以相关接口单元已完成为前提，该测试由测试leader不定期进行，原因：一、多留点时间给测试组员设计、修改测试用例；二、以测试leader的理解 去发现更深层次的问题，也可作为对组员测试工作的检查。） 五、缺陷的记录与修改 1、在测试范围1~6内发现的所有缺陷均记录在SPMS之同级评审--测试走查内； 2、在测试范围7内发现的所有缺陷以邮件的形式发送项目负责人； 六、人员职责划分 测试leader 1、测试版本控制；（开发部提交所有已完成页面的编译包） 2、测试任务的分配（最好是谁写测试用例谁负责测试）、测试时间的控制及测试 结果的发布； 3、查看所有缺陷，过滤一些非缺陷问题，整理共通问题并通知开发人员； 4、接口测试并跟踪修改结果；
XX系统源代码安全审计报告 XX部门 20XX年X月
目录 1.源代码审计概述 (1) 1.1.审计对象 (1) 1.2.审计目的 (1) 1.3.审计流程 (1) 1.4.审计组织 (1) 2.源代码审计范围 (1) 3.源代码审计详情 (1) 3.1.安全风险定义 (1) 3.2.安全缺陷统计 (2) 3.3.安全缺陷示例 (2) 3.3.1.隐私泄露 (3) 3.3.2.跨站脚本漏洞 (3) 3.3.3.SQL注入缺陷 (3) 3.3.4.XXX缺陷 (3) 4.总结 (3)
1.源代码审计概述 1.1.审计对象 描述本文档适用范围、场景等相关的背景情况，便于读者充分了解审计对象信息。1.2.审计目的 描述开展源代码审计工作的目的、依据、要求以及预期效果。 1.3.审计流程 描述源代码代码审计工作的流程，包括但不限于测试环境的搭建、测试方法或模式（例如工具测试、人工检查）、审计报告及整改方案的撰写，并明确各项工作的相关职责方。1.4.审计组织 描述开展代码审计工作组织情况，包括但不限于安全保密以及审计工作准备情况。2.源代码审计范围 描述被审计系统情况，包括但不限于源代码行数、源代码文件大小、设计语言及组件、开发软件环境、系统架构、编译器、系统类库、系统服务器及数据库等信息。 3.源代码审计详情 3.1.安全风险定义 源代码安全审计是运用工具和人工分析对源代码进行检查，检查系统软件存在的安全缺陷。根据安全缺陷可能存在的安全风险对检查中发现的各个缺陷给出了相对应的风险评价，并对风险评价中涉及到的各个等级给予一定说明和界定，如风险级别高、中、低并依次描述各级别对应威胁，示例如下：
一．目录文件组织 1.所有的文件名符合文件命名规范 2.文件和模块分组清晰 二．程序结构 3.所有的模块（函数和外部接口）定义清晰，模块分解清楚 4.结构设计能够满足机能变更，便于重构 5.模块中所有的数据结构都定义为局部的，并且通过定义好的函数进行访问 6.为外部定义了良好的函数接口，且修改时不影响其他代码模块 7.代码体系构架对空间和速度都已经进行考虑 三．代码组织 8.所有的代码行在80字符以内 9.每个程序文件都小于2000行 10.每个函数显示不超过100行 11.所有的变量声明每行只声明一个 12.所有的变量名都小于32字符 13.所有的函数名都小于64个字符 14.每个函数之间都用空行进行分开 15.所有的行每行最多只有一句代码或一个表达式 四．函数 16.函数注释清楚地描述函数和它的功能 17.函数的名字清晰的定义了它的目标以及函数所做的事情 18.函数的参数遵循一个明显的顺序 19.函数由并列关系的语句组成 20.函数高内聚，只做一件事情，并做好 21.所有的参数小于7个，且都被使用 22.函数使用了最少数目的return语句 23.函数检查了输入数据的合法性 24.函数异常处理清楚 25.函数设计已经考虑了将来的变化
五．数据类型与变量 26.Plugin中尽量避免全局变量的使用 27.每一个变量都在接近使用它的地方才初始化 28.变量的命名完全、明确的描述了该变量代表什么 29.同一种类型命名使用统一的前缀 30.所有的变量都被使用 31.所有的数组访问要考虑越界情况 32.变量在使用前进行必要的null值判断和处理六．条件判断 33.普通的情况在if下处理而不是else 34.最常用的情况最先判断 35.嵌套层次小于3层 七．循环 36.当有明确的多次循环操作，使用For循环 37.当有不明确的多次循环操作，while循环被使用 38.变量定义，数据库读写尽量在循环外进行 39.循环嵌套的次数小于3次 八．注释 40.使用统一的注释模版 41.每个类，每个函数都要有注释 42.注释量不低于20% 43.注释要随着代码改变而进行更新 九．其他 44.无用的代码和注解已经删除 45.页面的布局要符合统一操作说明
一、概述 代码审查（Code Review）是消灭Bug最重要的方法之一，这些审查在大多数时候都特别奏效。由于代码审查本身所针对的对象，就是俯瞰整个代码在测试过程中的问题和Bug。并且，代码审查对消除一些特别细节的错误大有裨益，尤其是那些能够容易在阅读代码的时候发现的错误，这些错误往往不容易通过机器上的测试识别出来。 1.1主要工作 1、发现代码中的bug; 2、从代码的易维护性、可扩展性角度考察代码的质量，提出修改建议。 3、是否符合java开发规范和代码审核检查表 1.2 基本流程 1、代码编写者和代码审核者坐在一起，由代码编写者按照UC（Use Case）依次讲解自己负责的代码和相关逻辑，从表现层->持久层; 2、代码审核者在此过程中可以随时提出自己的疑问，同时积极发现隐藏的bug;对这些bug记录在案。 3、代码讲解完毕后，代码审核者给自己安排几个小时再对代码审核一遍。代码需要一行一行静下心看。同时代码又要全面的看，以确保代码整体上设计优良。 4、代码审核者根据审核的结果编写“代码审核报告”，“审核报告”中记录发现的问题及修改建议，然后把“审核报告”发送给相关人员。 5、代码编写者根据“代码审核报告”给出的修改意见，修改好代码，有不清楚的地方可积极向代码审核者提出。 6、代码编写者 bug fix完毕之后给出反馈。 7、代码审核者把Code Review中发现的有价值的问题更新到"代码审核检查表"的文档中，对于特别值得提醒的问题可群发email给所开发人员。 1.3 责任 代码编写者，代码审核者共同对代码的质量承担责任。这样才能保证Code Review不是走过场，其中代码编写者承担主要责任，代码审核者承担次要责任。
代码审查(Code Review) 一、概述 代码审查（Code Review)是软件开发中常用的手段，和QA测试相比，它更容易发现和架构以及时序相关等较难发现的问题，还可以帮助团队成员提高编程技能，统一编程风格等，目前监控团队虽然提倡代码审查，也有相关的辅助工具，但是一直没有真正的推行起来，这半年的时间里，一些线上的bug如果经过代码审查，基本上可以避免的，大家也逐渐认识到代码审查可以有效地提高代码质量。 二、代码审查的作用 1、提高代码质量。 通过代码审查来发现bug及代码中的不规范，这是不容置疑的，通过代码审查，代码将更加整洁，有更好的注释，更好的程序结构。 2、提高开发者开发水平。 开发者知道自己编写的代码会被同事审查，将会更加认真的编写代码，也将会督促开者不断地学习、向有经验的同事请教。 3、提高程序的可维护性。 一份程序代码将会有更多的同事熟悉，更好的代码质量，自
然地也增加程序的可维护性。 4、提高开发者的对编码的责任感。 如果你在编程，而且知道将会有同事检查你的代码，你编程态度就完全不一样了。你写出的代码将更加整洁，有更好的注释，更好的程序结构——因为你知道，那个你很在意的人将会查看你的程序。没有代码审查，你知道人们最终还是会看你的程序。但这种事情不是立即发生的事，它不会给你带来同等的紧迫感，它不会给你相同的个人评判的那种感受。 5、传播知识 在很多的开发团队里，经常每一个人负责一个核心模块，每个人都只关注他自己的那个模块。除非是同事的模块影响了自己的程序，他们从不相互交流。这种情况的后果是，每个模块只有一个人熟悉里面的代码。如果这个人休假或——但愿不是——辞职了，其他人则束手无策。通过代码审查，至少会有两个人熟悉这些程序——作者，以及审查者。审查者并不能像程序的作者一样对程序十分了解——但他会熟悉程序的设计和架构，这是极其重要的。 三、代码审查的执行障碍 1、缺少代码审查的标准 缺少代码审查的标准，往往审查人员习惯性地根据自身开发经验去进行代码审查，容易变成去挑毛病，找bug，容易产生
如何进行代码审查 开始代码审查 从一开始，开发者就会互相帮助，如果测试中遇到了问题或是有新人加入到了团队，领导或是资深开发者就会审查他们的代码。除此之外，我们还聘请了外部专家进行安全代码审查。 系统发布后，我们决定更加主动一些，开始了基于风险的审查：项目中有人会编写一些风险较高的代码（比如说框架与安全代码、APIs、核心业务逻辑或是之前曾经出现过问题的地方），我们会审查他们的代码。在这个过程中，代码审查体现出了它的价值，我们收获颇丰。即便如此，我们还是更进一步，让代码审查成为一个标准的实践。 这并不是一夜之间就形成的。让团队相信代码审查的价值并不是什么难事，他们已经通过基于风险的审查获得了收益。不过要想改变人们的工作方式就不是那么简单的事情了，还要确保他们有足够的时间进行代码审查，理解并对反馈作出响应。此外，设计一个高效的代码审查流程也是需要花时间的。 一开始，我们让开发者选择好搭档并安排审查，但结果却有些混乱。有时，开发者会寻找那些好说话或是比较忙的人，这样审查就比较容易通过了；此外，两个开发者还有可能事先商量好，因此审查过程就会很快结束。由于人们并不知道要花费多少时间才能完成代码审查，因此审查经常会拖得很久，常常在代码已经完成测试甚至是发布后才完成。 由于大多数人并没有太多的代码审查经验，因此他们并不确定在审查时应该看什么，如何给出有意义的反馈等信息。开发者常常会被负面的批评搞得很沮丧，有时甚至会心烦意乱。 最后，我们决定由领导来完成大部分审查工作。虽然这会增加领导的工作量，也意味着他们没有太多时间编写代码了，不过这么做却是很有效果的。通常情况下，主开发者会对需求有着更好的理解，对代码的行为有着清晰的认识，这也意味着他们更有可能发现代码中的错误。由于是同一个人完成了大部分的代码审查，因此被审查的开发者会收到一致的反馈信息。 如何进行代码审查 在过去的几年间，我们进行代码审查的方式几乎没有发生过什么大的变化。 无论是谁编写的，无论代码的功能是什么，重要的代码变更是一定要审查的。我们并没有一个正式的审查会议，也没发现使用诸如Code Collaborator、Crucible等工具有什么必要性，不过现在看起来使用这些工具来管理和追踪审查有助于团队更好的起步。 有时，审查是面对面完成的，不过大多数时候都是离线进行的。审查者与开发者会交换信息，也许通过邮件发送文件，因为我们觉得这种方式更加便捷，也更加方便每一个人安排自己的时间。 随着时间的流逝，审查中的变化之处是审查者该看什么，以及看到的结果。
代码审查参考文档 代码审查（code review）是保证软件质量的一个重要环节，通过审查代码能够发现代码中可能存在的问题并给予纠正，这些问题可能包括设计上的、实现上的或者编程风格等多方面。本文档通过列举代码编写过程中的一些常见的细节问题，为代码审查环节提供参考。 Java代码 一、对象和变量 1.存在未被使用的变量 Eclipse会自动用下划线标出 2.对象的重复创建 这是系统中普遍存在的问题，比如： public class PrtGrpEndorsementBL { private GlobalInput mGlobalInput = new GlobalInput(); private boolean getInputData(VData cInputData) { mGlobalInput = (GlobalInput) cInputData.getObjectByObjectName( "GlobalInput", 0); return true; } } 这里mGlobalInput对象属于重复创建，因为在getInputData方法里会对它进行赋值，mGlobalInput使用的应该是从jsp页面传入的对象，所以改为private GlobalInput mGlobalInput = null; 又如： String msg = ""; if (..) { msg = "A"; } else { msg = "B";
} 这里msg同样属于重复创建，改为String msg = null; 3.变量的作用域 Java的局部变量可以定义在函数的任何位置，有部分由c转学java的程序员习惯将变量都定义在函数的顶部，因为在c里只能那样定义。但实际上变量的作用域越短程序的内聚性就越高，耦合性也更低，程序更容易理解，因此在java里应该在使用前才定义变量。 4.局部变量的危害 定义过多的不必要的局部变量是造成系统难以维护的原因之一，因为每增加一个局部变量我们就要先化时间去理解这个局部变量的意思，因此我们要减少局部变量的使用。用函数的返回值来替代局部变量是一种有效的办法，这就需要我们用重构的方式从大的函数中提出小的函数，用小函数的返回值来替代原有的局部变量。把大函数分解本身也可以降低程序的耦合度。 二、常量 1.硬编码，将代码写死 比较严重的情况是将险种代码写死在程序中，比如： if ("21301".equals(tLCGrpPolSchema.getRiskCode())) { ... } 这里将“21301”写死会为系统的维护和升级带来很大困难，最好是以险种定义的形式去动态获取险种代码。如果实在描述有困难，可以考虑建立一个Constants常量类，将其以常量的形式定义，这样以后维护只需改动一处即可。 业务系统中存在不少的状态标志，比如AppFlag的状态”0”为未签单，”1”为已签单，”2”为保全增人。虽然这些状态的意义日后已没有改动的可能，但直接将”0”、”1”、”2”写在程序里会导致程序可读性差，因此我们同样可以将其定义在常量类中，并加上注释，这样我们不必每次都去翻看文档或pdm，看常量类里的注释就行了。 2.禁用常量接口 Java的常量有一种不好的用法，就是将常量定义在Inferface中，这种方使定义的常量在使用时可以省去类名前缀，但会为以后的维护带来麻烦。因此不要试图用继承的方式去使用常量。
Code Review 代码审查 Code Review 代码审查 (1) 1．关于Code Review (2) 1.1 Code Review的目的 (2) 1.2 Code Review的前提 (2) 1.3 Code Review需要做什么 (2) 1.3.1 完整性检查（Completeness） (3) 1.3.2 一致性检查（Consistency） (3) 1.3.3 正确性检查（Correctness） (3) 1.3.4 可修改性检查（Modifiability） (3) 1.3.5 可预测性检查（Predictability） (3) 1.3.6 健壮性检查（Robustness） (3) 1.3.7 结构性检查（Structuredness） (3) 1.3.8 可追溯性检查（Traceability） (4) 1.3.9 可理解性检查（Understandability） (4) 1.3.10 可验证性检查(Verifiability) (4) 1.4 Code Review的步骤 (4) 2．Code Reivew的执行 (5) 2.1．事前准备阶段 (5) 2.1.1．CR的对象 (5) 2.1.2．CR的内容 (5) 2.1.3．评审规范和标准 (5) 2.1.4．选择CR活动的参与者 (5) 2.1.5．选择CR活动的实施方式。 (5) 2.2．实施阶段 (6) 2.2.1．准确记录 (6) 2.2.2．讲解与提问 (6) 2.2.3．逐项审查 (6) 2.2.4．注意气氛 (6) 2.3. 事后跟踪跟踪。 (6) 2.3.1. 确认发现的问题 (6) 2.32. 修正问题责任者 (6) 2.3.3. 修正结果确认者 (7) 3．注意事项 (7) 3.1. 经常进行Code Review (7) 3.2. Code Review不要太正式，而且要短 (7) 3.3. 尽可能的让不同的人Reivew你的代码 (7) 3.4. 保持积极的正面的态度 (8) 3.5. 学会享受Code Reivew (8) 相关资料 (8) 资料来源 (8)
深圳天源迪科信息技术股份有限公司 DIC-TS-DP-BIL-ABP-V6.0/PIMP 版 本：1.0 状 态：WT 中国电信融合计费平台维护研发项目V6.0 代码走读计划 文件建立/修改记录 本文件属深圳天源迪科信息技术股份有限公司所有， 未经书面许可，不得以任何形式复印或传播。
目录 1进度计划 (3) 2带评审物 ..................................................................................................... 错误！未定义书签。3成员角色 ..................................................................................................... 错误！未定义书签。4基本原则 ..................................................................................................... 错误！未定义书签。 4.1专利和著作权说明................................................................................ 错误！未定义书签。 4.2专利和著作权说明................................................................................ 错误！未定义书签。5走查过程定义 ............................................................................................. 错误！未定义书签。 5.1代码走查计划准备阶段........................................................................ 错误！未定义书签。 5.2个人代码走查阶段................................................................................ 错误！未定义书签。 5.3代码走查会议阶段................................................................................ 错误！未定义书签。 5.4缺陷修复与关闭.................................................................................... 错误！未定义书签。
代码审查规范 Version 1.0 2018年2月
目录 一、概述 (2) 1.1主要工作 (2) 1.2 基本流程 (2) 1.3 责任 (3) 二、代码审查检查表 (3) 三、代码审查的常见错误 (6) 3.1常见错误1# ：多次拷贝字符串 (6) 3.2常见错误2#：没有克隆(clone)返回的对象 (6) 3.3常见错误3#：不必要的克隆 (9) 3.4常见错误4# ：自编代码来拷贝数组 (10) 3.5 常见错误5#：拷贝错误的数据 (11) 3.6常见错误6#：检查new 操作的结果是否为null (14) 3.7常见错误7#：用== 替代.equals (14) 3.8 常见错误8#：混淆原子操作和非原子操作 (15) 3.9常见错误9#：在catch 块中作清除工作 (16) 3.10 常见错误10#：增加不必要的catch 块 (17) 3.11 常见错误11#； (18)
一、概述 代码审查（Code Review）是消灭Bug最重要的方法之一，这些审查在大多数时候都特别奏效。由于代码审查本身所针对的对象，就是俯瞰整个代码在测试过程中的问题和Bug。并且，代码审查对消除一些特别细节的错误大有裨益，尤其是那些能够容易在阅读代码的时候发现的错误，这些错误往往不容易通过机器上的测试识别出来。 1.1主要工作 1、发现代码中的bug; 2、从代码的易维护性、可扩展性角度考察代码的质量，提出修改建议。 3、是否符合开发规范和代码审核检查表 1.2 基本流程 1、代码编写者和代码审核者坐在一起，由代码编写者按照UC（Use Case）依次讲解自己负责的代码和相关逻辑，从表现层->持久层; 2、代码审核者在此过程中可以随时提出自己的疑问，同时积极发现隐藏的bug;对这些bug记录在案。 3、代码讲解完毕后，代码审核者给自己安排几个小时再对代码审核一遍。代码需要一行一行静下心看。同时代码又要全面的看，以确保代码整体上设计优良。