codereviewios有什么好的代码review

为什么每个团队都需要 Code Review

不少开发团队和创业公司都在纠结是否要执行 code review，既希望改进代码质量，又担心带来的负担会拖慢项目进度。

实时上，在软件开发中质量和效率往往并不是二选其一的关系。

能产出高质量代码的团队通常效率也非常高。

　　作为工程师的职业经历中，自动化测试和 code review 可说是能同时提高代码质量和开发效率的两个最有效的手段。

所谓 code review，和学术界的 peer review 类似。

Peer review 是由同事或同行对一位作者的作品进行查阅并提出建议和问题，只有当所有提出的问题都得到满意的答案后，作品才能发表。

对于 code review 来说，作品就是代码，发表就是把代码mit 到官方代码库。

　　在 Code Complete 这本书中讲述了两个很有说服力的案例。

在一项对同一个团队开发的很多个程序进行对比的研究中，没有经过 review 的程序平均每 100 行有 4.5 个错误，而经过 review 的程序平均每 100 行只有 0.82 个错误，也就是说 80% 的错误在 review 中被修正了。

AT & T 的一个 200 多人的部门在开始执行 code review 后，开发效率提高了 14%，而错误减少了 90% 左右。

　　除了减少缺陷，避免在诊断错误上浪费时间，review 的过程还可以通过相互的督促保证代码有好的可读性、文档、风格，并同时检查测试覆盖率等开发过程中的规范，从而提高团队的协作效率。

对于所有复杂的事情来说，总是越早发现问题，解决问题的成本越低。

　　对于经验不足或者刚开始一份新工作的人来说，通过 code review 可以得到更资深的人帮助，更快熟悉现有的规范和架构，在新的环境和团队中快速提升。

　　对于资深的工程师来说，让其他同事 review 代码，有利于在团队中传播经验、知识和好的实践。

身边的同事水平提高会让自己的工作也更高效。

并且谁都有需要休假的时候，无论是公司还是个人都不希望有太多工作因此而停滞，如果有平时就熟悉自己工作的同事，这个问题就很好解决。

　　像很多其他事情一样，code review 最难的就是迈出第一步。

一旦开始，花在 review 过程的每一分钟都会很快被成倍地赚回来。

如果你不在一个可以一下改变团队流程的位置上，那么至少可以和认同这件事的少数同事先开始实践，当价值开始体现的时候，相信其他人会乐于效仿。

为什么要用jupiter在代码中的作用

code review 有助于尽早发现代码中的问题,协调并逐渐统一各个编程人员的代码规范和习惯,以常用的Jupiter为例. Jupiter里，代码评审(code review)分为4个流程: Configuration(配置)：review发起者设置“Review ID”，指定要评审的代码，参与代码评审的人员，要讨论的问题等 Individual review(个人评审)：每个人独自审查代码，把可能出现问题的代码加入checklist Team review(团队评审)：大家在一起讨论之前检查出的问题代码，并决定如何处理 Rework：开发人员根据之前评审的结果，对代码进行修复 流程 Configuration 由评审发起者(代码作者、team leader或者PM)进行配置。

打开项目属性->Review选项页。

点击“New...”，设置相应的ReviewId和description: 接着添加本次要评审的代码和文件 添加参与代码评审的人员 接下来设置各种缺陷类型、严重性之类的。

然后就是指定存放评审数据的目录。

这个目录是相对于项目根目录的。

如下图: 设置完成后，Jupiter将在项目根目录下生成“.jupiter”文件，把此文件存入CVS。

现在评审发起者可以通知大家进行代码评审了。

可以通过发邮件的方式进行通知，通知的内容最好有以下部分： 即: 项目名称、Review ID、参与评审人员名单。

被评审代码的描述信息，如功能，需求等等 新增加和删除的文件 受影响但没有在Configuration中指定的组件 通知完毕后，各成员即可正式进行代码评审。

Individual review 从CVS取出最新的代码和.jupiter文件，在eclipse里->窗口(Window)->打开透视图(Open Perspective)->Review。

然后选择Individual Phase： 选择项目名称，Review ID和Reviewer ID(评审者ID)，然后就可以开始查看代码了。

在代码评审过程中，发现有问题的代码，即可在上面点击右键菜单->Add Review Issue...把问题添加到Jupiter中，指定问题类型、严重性和描述信息，点击保存。

完成个人的代码评审后，把Jupiter评审数据目录下的文件传入CVS，就可以一起进行讨论了。

Team review 大家在一起，使用一台电脑或者投影仪，选择Team Phase 现在Individual Phase里检查出的所有的问题都会显示在ReviewTable里，点击Go To就能链接到问题所在代码，然后大家讨论这段代码是否有问题，如何解决等等，把结果写到ReviewEditor里，保存。

所有的问题讨论出结果后，把Jupiter评审数据文件传入CVS，散会，各自回到自己位置，进行下一个步骤 Rework 从CVS取出最新的Jupiter评审数据文件，选择Rework Phase 选择自己的ID后，上一步骤中分配给自己的问题就会显示到ReviewTable里，一个一个地把问题修复吧，修复后把状态置为Resolved。

完毕后把Jupiter数据传CVS。

各自的rework完成后，各位评审者取出最新的Jupiter数据，关闭ReviewTable的过滤器，就能查看到本次评审中发现的各种问题，对各种问题进行验证，感到满意后可以把状态置为Closed，或者验证未通过,就置为Re-Opened。

总结 如此，便完成了一次代码评审…… 工具仅仅是一种辅助措施,更主要的是如何发挥积极主动性,不断提高编码水平和定制规范.

交叉评审什么意思

交叉评审也称代码复查，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。

通过工具来进行code review不在本次讨论范围内。

评审的内容： 编码规范问题：命名不规范、magic number、 System.out…… 代码结构问题：重复代码、巨大的方法和类、分层不当、紧耦合 工具、框架使用不当：Spring、Hibernate、AJAX 实现问题：错误验证、异常处理、事务划分、线程、性能、安全、实现过于复杂、代码可读性不佳、扩展性不好 测试问题：测试覆盖度不够、可测试性不好 代码评审不负责检查功能、逻辑是否正确，这些要靠单元测试和QA工作来解决 代码评审的好处： 提高代码质量 在项目的早期发现缺陷，将损失降至最低 评审的过程也是重新梳理思路的过程，双方都加深了对系统的理解 促进团队沟通、促进知识共享、共同提高 交叉评审——代码走查：团队成员互相检查代码 参与者可以是任意两个组员，或开发组长分别与每个组员结对进行 时机可以选择在下班前半小时，对当天改动的模块进行评审 代码作者讲解如何以及为何这样实现、评审者提出问题和建议 每次解决的问题要记录到SVN注释或JIRA 每次评审不要贪多，如下图所示：当一次评审超过400行代码时，能发现缺陷数显著降低——事倍功半 会审：以项目为单位，召开专门的代码评审会议 参与者：包括项目组全体成员，其它组的开发组长也应尽量参加 时机选择：开发进行到某一阶段时，对共性问题进行总结，对好的做法进行提炼和推广 会前准备工作： 组织者应通知各参与者本次评审的范围 参与者阅读源代码，列出发现的问题、亮点，汇总给组织者 准备工作要细致，需要给出问题详细描述以及相关代码在SVN上的URL地址等 评审代码的选择： 最近一次迭代开发的代码 系统关键模块 业务较复杂的模块 缺陷率较高的模块 会议议程： 如果是第一次会议，先由该项目开发组长做整体介绍 参加者依次发言，结合代码讲解发现的问题 每讲完一个问题，针对其展开讨论，每个问题控制在10分钟以内 如果问题不多，还可以安排该组成员对最近开发的代码进行地毯式的讲解和排查；或者针对某个方面对整个项目做评审，例如性能、安全性或测试 会后总结： 把会上提出的所有问题、亮点及最终结论详细的记录下来，供其他团队借鉴 未能讨论清楚的问题，会后解决 实行代码评审制度前的准备工作： 架构师提供开发规范、指南，为代码评审提供依据 建立起单元测试规范，否则无法达到测试覆盖度的要求、难以修正发现的问题 最好有样例代码库作参照，以提高代码评审的可操作性 提供评审案例：用评审前的代码与评审后优化的代码做对比 问题跟踪：对评审中发现的问题代码应加以跟踪，确保问题得以解决，防止复发 评审到什么程度： 进行全面的代码评审成本较高，也没有必要 对发现的问题要本着集体代码所有制的观点和就事论事的原则，因此建议把代码质量与团队绩效（而不是个人绩效）挂钩

ios有什么好的代码review

这两天，在微博上表达了一下Code Review的重要性。

因为翻看了阿里内部的Review Board上的记录，从上面发现Code Review做得好的是一些比较偏技术的团队，而偏业务的技术团队基本上没有看到Code Review的记录。

当然，这并不能说没有记录他们就没有做Code Review，于是，我就问了一下以前在业务团队做过的同事有没有Code Review，他告诉我不但没有Code Review，而且他认为Code Review没用，因为： 1）工期压得太紧，时间连coding都不够，以上线为目的， 2）需求老变，代码的生命周期太短。

所以，写好的代码没有任何意义，烂就烂吧，反正与绩效无关。