下载文档原格式
英文原文：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 和浏览器缓存等技术。
7. 全局都需要的信息保存在 application context 中。
编码习惯1. 没有被使用的变量要删除。
2. 针对不同的 Exception 要用不同的 catch 语句，而不是一个 Exception 解决所有问题。
3. 针对变量，方法和类要用相同的命名方法。
什么是代码审查？代码审查（Code Review）是一种软件开发过程中的质量保证活动，通过审查程序代码的质量和一致性，以发现潜在的错误、改进代码结构、提高可维护性和可读性。
代码审查通常由开发团队中的其他成员或专门的代码审查人员完成，以确保代码的质量和符合团队的编码标准。
代码审查的目的是多方面的：1. 发现错误和问题：代码审查通过仔细检查代码中的逻辑错误、潜在的安全问题、性能问题和其他潜在的缺陷，以及与规范和最佳实践不一致的部分。
通过早期的发现和修复，可以减少后期的修复成本和风险。
2. 提高代码质量：代码审查有助于提高代码的质量和可靠性。
通过审查代码，可以发现并纠正低质量的代码，改进代码的结构和设计，以及提高代码的可读性和可维护性。
3. 促进知识共享和团队合作：代码审查是团队合作的重要环节。
通过审查代码，团队成员可以相互学习和分享知识，了解项目中其他人的工作和设计思路，促进团队合作和沟通。
4. 遵循编码标准和最佳实践：代码审查有助于确保代码符合团队的编码标准和最佳实践。
这包括代码的命名规范、注释规范、代码风格、错误处理和异常处理等方面。
通过审查代码，可以确保整个项目的代码风格和质量保持一致。
代码审查的过程通常包括以下几个步骤：1. 提交代码：开发人员将自己编写的代码提交到代码审查工具或版本控制系统中。
代码审查工具可以帮助记录审查过程和审查结果。
2. 分配审查人员：代码审查由其他团队成员或专门的代码审查人员完成。
审查人员可以根据项目和团队的需要进行分配。
3. 审查代码：审查人员对提交的代码进行审查。
他们仔细检查代码的质量、结构、逻辑、性能等方面，并与编码标准和最佳实践进行比较。
4. 提出问题和建议：审查人员对代码中发现的问题和改进提出评论、建议和问题。
这可以是关于代码逻辑的问题、潜在的错误、可读性和可维护性的改进等。
5. 讨论和解决问题：开发人员和审查人员之间进行讨论，解决代码审查中发现的问题和疑问。
谈谈代码评审（codereview） 什么是代码评审(code review)? 根据维基百科的定义，代码评审是⼀种通过若⼲⼈员检阅源代码⽅式来进⾏的软件质量保证活动。
根据软件⼯程的经典理论，代码评审应该是收益很⾼的活动，因其产⽣在Coding阶段（属于开发⽣命周期的早期），在开发⽣命周期越早发现问题，解决问题的成本越低。
⼯程实践也能印证这个结论。
代码评审有以下⽬标：提⾼代码质量和可维护性（可读性，⼀致性）发现代码缺陷知识经验传承发现更好的解决⽅案满⾜ＱＡ指导⽅针 本⼈根据针对⽹络上某代码评审最佳实践的公开⽂章谈谈⾃⼰的想法。
原则１：每次只评审⼩于２００～４００⾏的代码。
－－》 我的观点：这个只要是考虑到⼀次评审的代码过多，评审者发现问题的能⼒将⼤量缩⼩。
如果⼀次评审过多代码，会对评审者带来智⼒和⼼理两⽅⾯的挑战。
从智⼒上来说，抛开极少数智⼒超群者不谈，对普通⼈来说，⼀次评审更少量的代码更容易理解代码的意图（同时减少了与代码作者的沟通成本，提⾼效率）。
这也是符合分⽽治之的解决问题⽅法论的。
从⼼理上来说，⼀次评审过多代码会对评审者产⽣倦怠感，评审者主观上通常会降低评审的细致度。
根据我的经验，如果某项软件开发任务代码量⽐较⼤，可将此任务分解为若⼲⼦任务。
⼦任务的划分粒度尽量做到⼀周的代码提交量（提交的代码需要测试通过）。
当然，⼦任务的划分是建⽴在良好的设计⽂档基础上，否则⼦任务划分的随意度⽐较⾼且⼯作量评估容易不准确。
原则２：代码评审速度应⼩于每⼩时３００～５００⾏。
－－》 我的观点：这条主要是考虑评审的细致度，细致度越⾼越能发现更多问题。
换算⼀下，⼀个２０⾏的函数，评审时间应不少于２～４分钟。
原则３：检查清单（checklist）可以⼤幅改善评审结果－－》 我的观点：检查清单对代码作者和评审者都有作⽤。
对代码作者来说，可以在编码的时候就犯⽌犯类似的错误。
对评审者来说，可以帮助评审得更全⾯，特别是找出遗漏的问题。
CR（代码审查）什么是代码审查代码审查（Code Review）是指通过检查、分析和评估代码来找出其中的错误、缺陷和改进点的过程。
它是软件开发过程中非常重要的一环，可以帮助开发团队提高代码质量、降低维护成本，并加强团队合作和知识分享。
为什么进行代码审查进行代码审查有以下几个主要原因：1. 提高代码质量通过代码审查，可以找出潜在的错误、缺陷和不规范的编码风格。
及早发现和修复这些问题，可以避免它们在后续的开发和测试阶段引入更大的问题。
同时，通过与其他团队成员共同讨论和评估，可以提供更好的解决方案，并促使开发人员思考更合理、更高效的实现方式。
2. 知识分享与技能提升在代码审查过程中，不仅是被审查者能够从其他团队成员中学习到新知识和技巧，而且对于参与审查的人来说也是如此。
通过参与他人的代码审查，可以学习到其他人在设计、实现和优化方面的经验，并将其应用到自己的开发工作中，从而提升自己的技能水平。
3. 加强团队合作与沟通代码审查是一个团队协作的过程，通过共同讨论和评估代码，可以促进团队成员之间的交流和合作。
通过互相学习、指导和支持，团队成员能够更好地理解彼此的工作，并共同努力提高整体的代码质量。
此外，代码审查还可以帮助团队建立一致的编码规范和最佳实践，提高开发效率和协同工作能力。
如何进行代码审查要进行有效的代码审查，需要遵循以下步骤：1. 确定审查目标在开始代码审查之前，需要明确审查的目标和范围。
这可以包括特定功能模块、新添加或修改的代码段等。
明确审查目标有助于提高审查效率，并确保关注重点。
2. 审查准备在开始实际的代码审查之前，需要对待审查的代码进行准备。
这包括了解相关需求、设计文档和测试用例等。
通过对上下文信息的了解，可以更好地理解待审查代码，并找出其中可能存在问题或改进点。
3. 代码审查在进行代码审查时，可以考虑以下几个方面：•代码结构和组织：检查代码的结构是否清晰、模块划分是否合理，并确保代码符合团队的编码规范和最佳实践。
代码审查（CodeReview）什么是代码审查 代码审查（code review）是⼀种可以有效帮助提升代码质量的途径，它是对源代码进⾏系统化的审查，可以找出及修正软件开发初期未发现的错误及可以对代码进⾏优化指导，⽬的在于提升代码质量及开发者技术⽔平。
代码审查的好处 1. 帮助提⾼代码质量，修正代码错误，让软件产品的问题更少更容易维护。
2. 有助于熟悉项⽬中各个模块，我们系统⼤都是由多⼈开发，平常每个⼈都负责⾃⼰那⼀块，对于其他⼈写的了解并不够，代码审查时候会联系代码修改模块的上下⽂及相应的业务，这样让不了解这块内容的团队成员了解了这块内容。
3. 帮助新⼈融⼊团队，因为⼀个新⼈加⼊团队对团队的技术规范及业务需求不是很熟悉，在代码审查的时候会对实际和具体的代码和需求进⾏阅读及分析，可以帮助新⼈了解业务，也会设计到代码层⾯的技术讨论，让新⼈有了直观的了解。
4. 可以帮助团队成员成长，在代码审查的时候会找出⼀些不合理的及可以优化的地⽅，团队成员可以在相互的讨论中了解解决问题及思考问题⽅式⽅法，补充和完善对⾃⾝对问题的思考。
以后再遇到相似的问题可以有更合适的⽅案。
代码审查的代价 需要额外的时间和精⼒。
当然可以选择⼀个合适的时间或者⾃⼰进⾏代码审查。
代码审查的时机 代码审查需要及时进⾏的，⽐如当⼀个项⽬快结束的时候就可以进⾏代码审查。
不能当项⽬上线了或者代码的作者进⼊别的项⽬在进⾏代码审查就晚了。
1. 当有代码变更被提交到远程仓库了就可以进⾏代码审查。
2. 代码通过git提交，开发git分⽀被合到测试分⽀或者master分⽀时候，也就是merge request（MR）可以由合并分⽀的负责⼈负责代码审查。
代码审查的频率 1. 集中式：团队所有成员⾯对⾯在⼀起，⽐如在⼀个会议室，通过会议共享屏幕翻阅仓库代码并讨论，这种⽅式沟通效率⾼，但是需要协调团队所有成员时间。
这种最好频率不要太⾼。
2. 异步式：这种可以借助⼯具来随时进⾏代码审查。
怎么进⾏代码审查（CodeReview）代码审查的重要性代码审查是熟悉软件架构，了解软件业务逻辑的好⽅法。
学习代码是需要切⼊点的，⼀个上百万⾏代码的系统，从哪⾥开始着⼿？只能⼀个模块⼀个模块，⼀个组件⼀个组件的来熟悉，掌握。
实现⼀个⽐较⼤的功能，你应该不会是唯⼀的开发⼈员，从系统架构师输出的系统设计，然后到各个团队中技术 Leader 输出的 component 级别的设计，到开始实现时，应该会把功能分为不同的模块有不同的开发⼈员协同实现。
这是个学习的机会，不要只局限于⾃⼰这部分，为了了解这个⼤的功能，甚⾄和这个功能相关的其他已经实现的功能，你同样需要关注其他⼈的⼯作。
有⽬的的看代码和漫⽆⽬的的浏览效果是不⼀样的，你已经对新功能有所了解，审查代码之前，你认为代码会怎么写，别⼈哪⾥和你想的不⼀样，旧功能和新功能是如何相互影响的等等，⼼⾥怀着问题，你的学习速度会更快，记得更加深刻。
代码审查是你提⾼⾃⼰的好⽅法。
前提是 team 中有经验丰富的开发⼈员的存在。
也就是⼤⽜，不要错过让他看你代码的机会，不要害怕他会为你写的代码挑出⼀⼤堆问题，有⼈说你⾃⼰写的代码就像⾃⼰的孩⼦，见不得别⼈说半点不字，不要固执，要内⼼平静的，客观的去看待你所写的代码，发现并解决问题才能提⾼你⾃⼰。
也不要错过去review⼤⽜代码的机会，看看⼤⽜写出来的代码是怎样的，你可以取其精华。
代码审查是需要功⼒的。
⽹上有帖⼦说程序员的资深与否和⼯作年限没有必然联系，你是5年⼯作经验还是⼀个经验⽤了5年，这需要你去刻意练习，刚开始 reveiew 代码的时候你可能不习惯，也可能很痛苦，⾯对的⼀屏幕的代码不知如何下眼。
但有⼀句话，如果你觉的内⼼很舒服，你就是在原地踏步。
觉的痛苦说明你是在爬坡，刻意的去联系⾃⼰的⼤脑吧，今天你看⼀页代码可能⽤了⼀个⼩时，没有发现问题，但是坚持⼀个⽉甚⾄三个⽉之后，你看⼀眼就能够发现代码中的缺陷，恭喜你，你的功⼒加深了。
CodeReview Idea插件是一款用于进行代码审查的工具，可以帮助开发人员更好地协作和分享代码审查的意见和建议。
下面是CodeReview Idea插件的使用方法：
安装插件：安装CodeReview插件。
配置插件：在项目设置中配置CodeReview插件，包括设置代码仓库地址、分支等。
开始审查：选择需要审查的文件或文件夹，右键选择"Add to Code Review"开始审查。
填写审查意见：在弹出的对话框中填写对代码的审查意见和建议，可以选择不同的代码块进行注释和描述。
提交审查：完成审查后，可以选择提交审查，将审查结果推送到代码仓库中。
查看和回复审查结果：在CodeReview工具窗口中查看和回复其他人的审查结果。
导出审查结果：可以将审查结果导出为HTML或PDF格式的文件，方便团队成员查看和讨论。
需要注意的是，CodeReview插件的具体使用方法可能因版本不同而有所差异，建议参考官方文档或插件说明进行操作。
软件开发中的代码审查与审核在软件开发过程中，代码审查和审核是必不可少的环节。
通过对代码进行审查和审核，团队成员可以发现并纠正潜在的代码缺陷，提高代码质量，减少错误。
本文将介绍代码审查和审核的基本概念、作用以及最佳实践。
一、代码审查和审核的定义代码审查（code review）是一种通过检查获取代码来识别错误、优化代码和提高代码质量的过程。
它通常由团队成员或专家开发者进行，他们会定期地检查代码并提出建议改进。
代码审查可以在不同的阶段进行，例如在开发中、测试前或发布前。
代码审核（code inspection）通常是在开发过程的早期阶段进行的一种活动。
代码审核是一项严格的、程序化的过程，它旨在为软件产品的开发提供质量保证，并确保代码符合规范、标准和设计要求。
二、代码审查和审核的作用1. 提高代码的质量代码审查和审核可以帮助团队及时发现和纠正代码中的错误。
它可以帮助团队避免在开发过程中增加bug，降低代码质量。
2. 减少错误和延误通过代码审查和审核，团队可以发现潜在的缺陷并及时修复，这样可以减少错误和延误。
3. 提高团队的技能通过观察其他人的代码、看到其他开发者的解决问题的方法，团队成员可以对自己口袋中的技能进行提高。
三、代码审查和审核的最佳实践1. 审核和审查应该是有计划的团队应该有一个明确的计划，规定何时进行审查和审核。
例如，在完成某个功能时，应该对代码进行一次审查；在保持代码更新时，应该进行定期的审核。
2. 团队成员应该具备针对性的技能团队需要一个具有针对性的技能集来执行审查和审核。
过程中，正在被审查或审核的代码需要专业人员的对其进行评估。
3. 审核和审查的量要适度团队应该在一定的时间内处理适量的代码，以便在短时间内实现审查和审核的目标。
如果关注的代码量过大，代码审核和审查可能会超时导致随意的结果丢失，更损失人员的已有知识和技能。
4. 使用代码审查和审核工具使用代码审查和审核工具可以大大简化过程，并提高效率。
代码审查在软件开发中的作用及技巧代码审查（Code Review）是指对软件开发过程中所产生的代码进行检查和评估的一种活动。
它在软件开发中扮演着重要的作用，可以帮助团队提高代码质量、发现潜在问题、减少后期维护成本。
本文将介绍代码审查的作用，以及一些技巧来优化和提升代码审查的效果。
一、代码审查的作用1.发现潜在问题代码审查能帮助开发团队发现代码中的潜在问题，如潜在的逻辑错误、安全漏洞、性能瓶颈等。
通过多人的眼睛进行审查，可以降低由于疏忽或者思维定势导致的问题。
2.提高代码质量代码审查可以帮助团队成员互相学习，分享最佳实践，并且借助其他人的经验来提高自己的编程水平。
通过互相研究和讨论，可以发现更好的解决方案，并使得代码更易读、可维护和高效。
3.减少后期维护成本在软件开发的整个生命周期中，维护成本是一个很大的开销。
通过代码审查，可以尽早发现并修复问题，减少后期维护的工作量和风险。
有效的代码审查流程可以在早期阶段捕获问题，并提供及时的反馈，从而降低未来的修复成本。
二、代码审查的技巧1.明确审查目标在进行代码审查之前，明确审查的目标非常重要。
审查者要了解代码的背景和设想，并明确被审查代码所需达到的标准。
同时，也要对所审查代码的功能、性能、可读性、可维护性等方面有清晰的了解。
2.遵守审查准则建立一套明确的审查准则非常重要，这有助于团队成员在审查过程中保持一致的标准，并提高审查的效率。
审查准则可以包括代码布局、命名规范、错误处理、注释规范等方面的规定。
3.使用合适的工具代码审查通常需要使用一些工具来辅助处理，例如静态代码分析工具、版本控制工具等。
这些工具可以帮助发现一些常见的问题，并提供一些自动化的代码检查。
合理运用这些工具可以提高审查的效率和准确性。
4.在适当的时机进行审查代码审查不应该仅限于开发周期的最后阶段，而是应该在整个开发过程中有计划地进行。
在功能开发完成后，就可以开始进行初步的回顾。
这样可以尽早发现问题并予以解决，防止问题进一步扩大，从而降低后期的风险和成本。
代码审查参考文档代码审查〔codereview〕是保证软件质量的一个重要环节，通过审查代码能够发现代码中可能存在的咨询题并给予纠正，这些咨询题可能包括设计上的、实现上的或者编程风格等多方面。
本文档通过列举代码编写过程中的一些常见的细节咨询题，为代码审查环节提供参考。
Java代码一、对象和变量1.存在未被使用的变量Eclipse会自动用下划线标出2.对象的重复创立这是系统中普遍存在的咨询题，比方：publicclassPrtGrpEndorsementBL{privateGlobalInputmGlobalInput=newGlobalInput();privatebooleangetInputData(VDatacInputData){mGlobalInput=(GlobalInput)cInputData.getObjectByObjectName("GlobalInput",0);returntrue;}}那个地点mGlobalInput对象属于重复创立，因为在getInputData方法里会对它进行赋值，mGlobalInput使用的应该是从jsp页面传进的对象，因此改为privateGlobalInputmGlobalInput=null;又如：Stringmsg="";if(..){msg="A";}else{msg="B";}那个地点msg同样属于重复创立，改为Stringmsg=null;3.变量的作用域Java的局部变量能够定义在函数的任何位置，有局部由c转学java的程序员习惯将变量都定义在函数的顶部，因为在c里只能那样定义。
但实际上变量的作用域越短程序的内聚性就越高，耦合性也更低，程序更轻易理解，因此在java里应该在使用前才定义变量。
4.局部变量的危害定义过多的不必要的局部变量是造成系统难以维护的缘故之一，因为每增加一个局部变量我们就要先化时刻往理解那个局部变量的意思，因此我们要减少局部变量的使用。
代码审查(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人员也不负责检查代码的功能是否正确，也就是说，需要复查的代码必须由开发人员或质量人员负责该代码的功能的正确性。
