被问的时候，可能项目才定下来，仅仅知道大概的功能模块，非功能性需求还模糊不清，甚至团队成员都没到位。但是上级、销售、客户急切地要知道，这个项目什么时候才能完成？

被问的时候，也可能项目已临近结束，或者说临近当初计划的交付日期。然而待完成的功能还有一堆，测试出来的bug有一大堆，客户又提出了新的需求，团队正有人要离职 …。但是上级、销售、客户非常急切地要知道，这个项目到底什么时候才能完成？

这还不算糟糕。更头疼的问题是：“再有三周，项目应该完成了吧？”

因为后者根本不是问题，而是命令。项目经理必须要能够合理解释为什么三周不能够完成项目；或者说明在三周内，能够完成什么。

我们都用过MS Project， 但是那上面的漂亮表格对这样的困境毫无帮助。相反，正是Project 中的甘特图和日程表，埋下了陷阱。因为，在Project 中无法预估需要多少工作日才能完成模糊不清的需求，也无法体现实际情况发生变化后对进度的影响。

当我们讨论进度的时候，其实包含了两个未知的变量。第一是完成需求所要的工作量，包括需求定义、开发内容边界；第二是团队的工作能力，包括成员的行业知识专业技能，成员之间、成员和外部的沟通能力，等等。

关键就在于，这两项都是变量。如果任务是搬一千块砖头，每分钟每人能搬10块，那么结果是显而易见的。

在敏捷开发中，采用相对估算和迭代求精的方法来处理项目进度的问题。

首先是工作量。用估算代码行数或者界面元素的方式，就像论斤卖书一样，只适用于粗制滥造的软件生产过程。用户需要的并不是代码或者按钮，而是可靠易用的功能。

在敏捷开发方式中，先由用户和设计人员粗略估计各个功能模块的相对规模和难度，给出一定的分值。分值不代表具体人月，起相对比较的作用。例如有查询、显示、修改三个模块，如果实现显示模块的工作量是10分，那么查询模块可能是15分，而修改为20分。

下一步，选择一个工作量估分最低的模块，例如这里是显示模块，然后进一步考量其工作量。例如要准备数据库、设计界面、执行查询，显示内容等等。假设这轮估算得出此模块需要10人天，从而得出单位分值对应的人天为1；那么，整个项目就需要45人天。

这个估算建立在对项目的初步了解上，主要依赖项目经理的经验。有偏差？没关系。接下来通过迭代来求精。先来实现显示模块，如果事实上花费了12人天，那么根据比例关系，剩余内容的估算大约就是42人天。

当然，比例关系也不是一成不变的。随着模块的逐个完成，项目经理对项目的认识也在加深，他可以再调整剩余模块的相对分值。

在实际操作中，项目经理首先按照优先级排列功能模块。然后把高优先级的模块尽可能地细分，再选择分值最小的模块开始开发。统计总工作量时，按比例累加其他模块的工作量，并加一定的调整系数，因为模块的复杂度不是线性增长的。每次迭代开发完成后，逐步降低调整系数。通常4~5次迭代后，可以将调整系数归零。

在上面的例子中，第一次估算的初步结果是45人天，因为完全是凭经验，因此要给较大的调整系数，比如说0.4，因此给出的估算工作量区间为[45*0.6,45*1.4],即27到63人天之间。为保险起见，项目经理上报的工作量为70人天。

第二次估算，剩余内容的初步估算为42，调整系数下降为0.3，因此给出估算区间为30到50人天之间。依此类推，通过不断迭代，对剩余工作量的估算将越来越精确。

这样估算的好处在哪里？

首先，工作量变量的很大一部分因素，存在于非功能需求，例如界面的美观程度。而同一项目的不同模块之间，非功能需求往往是一致的，相对估算法过滤了这一层复杂度。团队能力这一变量因素也是如此。当然，随着项目的进展，成员的开发能力应该有一定的上升，但随着加班出差等因素，投入程度也可能下降，因而会相互抵消。总之在周期6个月以内的项目中，很少出现团队工作能力戏剧性变化的情形。因此相对估算也过滤了这个复杂度。

其次，迭代求精的方式让项目经理对估算时间更有把握。最初出现偏差是必然的，但只要团队稳定，没有大的需求变动，估算范围将迅速收缩。这比一次性报数更准确。

它的额外好处是，敏捷开发是遵循优先级的，即使对剩余时间（即低优先级模块的开发时间）的估算不十分准确，影响也不是非常大。

对比一下甘特图方式，在开发初期就要把各个模块的开发时间估算出来以统计总量，这就是瀑布开发的模式。

进度问题的另一方面，是项目经理如何了解团队以及每个开发人员的开发速度。当任务分配之后，项目经理如何做到心中有数，估算任务实际完成时间。

敏捷开发过程中，由开发人员自己来估算完成该任务所需要的时间。当然，每个人的能力不同；每个人的心态也不同，有的人保守，有的人乐观。没关系，还是靠迭代来逐步求精。

在每天的例会上，开发人员被要求对当前任务的剩余开发时间做重估。不同于Project 统计每人每天在任务中花费了多少时间，敏捷方式只关心这项任务还需要多少时间去完成，直到归零，然后再来统计实际的工作时间。

为什么？因为统计开发过程中的花费时间是毫无意义的。这和搬砖头不同，也许昨天用了8个小时没有一点进展，今天一旦想通了就事半功倍。我们真正关心的，就是到底还需要多少时间来完成任务，而不是已经花费掉不可恢复的时间成本。

在每天例会中，项目经理需要注意时间曲线保持水平的成员，他是不是遇到瓶颈了，是否需求帮助？也要留意时间曲线下降幅度过大的成员，他发现了什么好的办法，有没有低估需求？这样，项目经理会更面向结果，只要按计划保证质量完成任务就行，成员到底花了多少时间是个人的事。传统做法记录每个人每天的工作内容，第一是因繁琐而失真。其次，一旦上级发现某人工作时间不够（即便他完成了任务），忍不住会派新任务，从而造成越干活越多，反过来打击程序员的积极性。

敏捷估算的关键之处，是把成员能力这个变量的估算，交给最合适的人去做，即程序员本人。然后通过比较历次迭代时的预估和实际时间，给出校正系数，以避免程序员过于保守或过于乐观。这肯定不是绝对准确的，但效果往往比项目经理自己拍脑袋估算，然后强行指定deadline 要好得多。

在敏捷开发中，做计划比计划本身更重要。项目经理需要时刻向前考虑，考虑各种动态因素，而不是死报着计划本身。在进度估算的时候，项目经理应该在不同阶段，根据实际情况，给出合乎情理的回答。

在谈到架构师的角色时，Hollander指的是“解决方案架构师”或者应用架构师。他不是指企业架构师或者其他的专业人士（专精于特定的领域，例如消息或基础设施）。

Hollander的团队采纳了由4周迭代以及最后的稳定阶段（几天代码冻结的时间）组成的流程，实施了每日站立会议、每日构建与自动化测试的持续集成等实践，并采用了许多角色：

• PjM——项目经理，类似于Scrum Master，确保团队遵循了流程
• PdM——产品经理，也被称为客户或Product Owner，决定产品应该是什么样子
• 架构师——解决方案/应用架构师
• 开发人员——开发团队
• 测试人员——测试团队
• 用户体验设计人员（UX）——用户体验团队
• 发布人员——承担构建和发布的职责，负责维护构建的流程

Hollander针对解决方案架构师如何在敏捷团队中取得成功，提出了最重要的十件事情：

1. “正好足够”的预先设计——除了非常简单的项目，一定时间的预先设计（例如，1到2周）是绝对必要的，其时间长短会取决于应用的类型——网络应用程序、智能客户端（smart client）、移动或批处理，基本的功能需求是什么，是长期的解决方案抑或是折衷的、暂时的方案，都要弄清楚。预先设计的目的是要决定：使用什么技术——例如，ASP.NET或MVC，应用程序是什么类型——2层、3层抑或是面向服务的应用，如何访问数据库——存储过程、实体框架、LINQ、依赖注入（DI）。一篇简短的文档就可以包含所有这些信息以供大家参考。
2. 从垂直分片开始——是指从一小块功能开始（例如登录页面），尽可能地在垂直方向把它切分为很多层，从而把前一阶段所决定的所有技术结合在一起。这将验证设计决策的正确性，而且所有的技术可以一起工作，并且将向开发者展示在开发新代码时可以遵循的模式。如果发现最初的设计决策不当，此时是一个合适的修改时间。
3. 在每次迭代中的Just-in-time设计——在每个4周迭代的中段，项目经理、产品经理和架构师应该聚在一起讨论在下一个迭代中要完成的需求，确保他们每一位都同意这些需求，重要性更高的事情放在了前面处理，而且每个人对一切事情都非常清楚。这些讨论在当前迭代中会以不太明显的方式延续一个星期。接下来的一周，也即当前迭代的最后一周，架构师复审下一次迭代的需求，作出必要的设计决策，以便团队可以在下一个星期基于这些决策开展工作。如果需求与以往相当不同，那么，架构师会开发一些原型，编写一些代码来证明概念，绘制一些图表，然后把所有这些东西集编为5页的文件以供参考。这不是为了制定出有利于开发人员的详细设计方案，而是要确保新的需求满足全局的要求。
4. 信任你的团队...但要跟他们在一起——这关乎架构师与开发人员的关系。架构师需要确保他没有逾越自己的角色，没有独占所有“做决定”的乐趣，使得开发人员的工作变得无聊。与此同时，架构师需要给团队提供指导，解决那些可能会导致开发人员停顿的困难问题。架构师每天都应该与每位开发人员接触，获悉他们在做什么，并且在他们遇上编程问题的时候给予帮助。特别是当开发人员不喜欢寻求帮助，试图花上整整一个礼拜的时间来自行解决问题的时候，这种帮助尤为需要。这种关系也适用于PjM和测试/构建/发布团队。
5. 编写代码！——架构师应该知道代码的质量如何，这样才会对他做出的决定所产生的影响有更好的理解。他也可以整明白何时重构是必须的。 编写代码的架构师在开发团队中有更好的声誉。也就是说，Hollander并不认同（设计和开发）职责的泾渭分明。他还认为，架构师仍然是架构师，他不一定要像普通的开发人员一样擅长于编写代码。
6. 参与一切——架构师参与所有与项目有关的会议：设计、开发、代码评审、需求规划等，这是有好处的，因为他能够以更广阔、更清晰的视角看待正在发生的事情，而且他能够通过告知产品经理其决定的潜在后果，从而帮助他/她避免在早期阶段做出错误的决定。
7. 推动质量文化——一个成功的团队，一个人人都想成为其中一分子的团队，是建立在质量文化之上的：没有人偷工减料；没有人提交拙劣代码；如果设计中有一个重大的缺陷，它绝不会不知不觉地混过关；所有人都是诚实和开放的，寻求整个团队达到最佳的结果。Hollander承认，建立这样一个团队很难，但并非不可能。首先，架构师应该在一开始就创建一些规则，这些规则不会因为开发人员不喜欢就随着时间而改变。比如决定编写单元测试，再比如在每次提交以前都要进行代码评审，包括由架构师提交的代码。如果评审人员（可以是团队中的任意一位）不认可代码，代码就不能提交。
8. 知道何时需要改变——架构师应该非常灵活，随时准备好在设计需要改变的时候去改变设计。早期的解决方案也许不再适合，抑或是新的需求需要不同的方法。
9. 屏蔽来自外部的随机请求——虽然这通常是项目经理/Scrum master的职责，但架构师可以保护团队不受外部请求的影响，这些影响往往会分散团队的精力和浪费真正工作的时间。举个例子：业务团队可能想要以某种特定的方式完成某些特定的事情，而他们的请求并不全然合理，也并不是必须实现。 
10. 撰写文档...但只有当有人需要阅读它们的时候——Hollander并不提倡记录一切，也不提倡根本不撰写任何文档。他认为有必要取得一个平衡——只编写一定数目真正有帮助的、有人会去阅读的文档。文档在记录详细设计的决定（比如数据模型）方面是很好的载体。迭代的设计决定，虽然它们由整个团队在迭代开始之初讨论得出，但我们仍然建议将它们记录在5页的文档之中，以备开发人员日后不记得架构师言论的时候进行查阅。而当最开始的开发人员和架构师离开项目、加入其他项目之后，新加入项目工作的人也能借助于这些文档理解某些决定的来龙去脉。 

综上所述，Hollander指出，架构师应该确保他从理论上和实践上都是团队的一分子。架构师不应该编写所有的代码，而只是其中一小部分，他不去测试或部署这些代码，但他要确保整个流程的顺利进行。
转载自：http://www.infoq.com/cn/news/2010/09/Tips-Architect-Agile-Team

Java项目开发过程中，由于开发人员的经验、Java代码编写习惯，以及缺乏统一的标准和管理流程，往往导致整个项目的代码质量较差，难于维 护，需要较大的测试投入和周期等问题。这些问题在一个项目组初建、需求和设计均具有不完全可预期性和完备性的全新项目中将尤为突出。

如图1所示，敏捷开发过程经历需求调研，用例分析和用例分解，进入开发迭代阶段。在每个迭代过程中，可以采用以下步骤来保证和提高整个项目的代 码质量：统一编码规范、代码样式;静态代码分析(staticcodereview);单元测试;持续集成;代码评审和重构 (Review&Refactor)。下文将针对每个步骤和其所使用的工具、方法进行详细描述。

图1.敏捷开发中的Java代码质量保证步骤

步骤一：统一编码规范、代码样式

规范统一的编码会增加项目代码的可读性和可维护性，但实际情况往往是项目组内的Java代码开发人员的编码风格常常各不相同，这可能是由于不同 的经验习惯或者缺乏编码规范方面的学习造成的。这样一来，其他项目成员或者维护人员在阅读项目代码时就需要花费更多的时间来理解代码作者的意图，所以制定 并采取统一的编码规范就显得很重要。编码规范主要应包含以下几个方面：

◆一般规则和格式规范。例如代码缩进、程序块规范、每行最大代码长度等。

◆命名规则。例如包名、类名、变量、方法、接口、参数等命名规范

◆文档规范。例如类文件头声明、类注释、成员变量和方法注释等规范。

◆编程规范。例如异常、并发、多线程等方面的处理方式。

◆其他规范。例如日志格式、属性文件格式，返回值和消息格式。

项目的编码规范可以参考已有的一些Java编程规范书籍和其他相关资料并结合项目的本身来制定，可供参考的书籍有《Java编程风格》(英文书 名为：TheElementsofJavaStyle)。编码规范要形成文档，而且要简洁明了，并组织项目成员一起学习，确保所有成员正确理解所有条目。

一旦编码规范确定，就可以利用Eclipse自身提供的功能来控制代码样式和格式。具体做法是，点击Eclipse的 Windows->Preference菜单项，在打开的Preferences对话框的左侧栏中找到Java节点下的子项CodeStyle(如图2)，该项 和它的子项允许您对Java代码的样式进行控制。

图2.Eclipse代码样式设置窗口

例如，为了使用自动格式化工具，可以在Eclipse提供的默认代码格式配置的基础上建立自定义的格式。在Formatter面板中，点击 New，输入新的名字并选择一个默认的配置作为初始化格式，如图3所示。

图3.创建新的代码格式配置

单击OK后就可以在新打开的窗口中进行修改定制自己需要的格式。如图4所示。

图4.创建新的代码格式配置

修改完成后点击Apply保存所作修改。同时可以点击Export将当前的格式定义导出成一个XML文件，这样项目组的其他成员就可以很方便通 过点击图3中的Import按钮来导入该XML文件来使用同一个代码格式定义。

这样每次在提交代码到版本控制服务器前就可以通过Eclipse界面里的Source->Format菜单来对代码进行格式化，从而 使整个项目的代码具有相同的格式。同样可以通过对CodeStyle下的其他项目进行设置来帮助对Java代码的样式进行控制。将所有这些样式文件导出成 XML文件后，同编码规范一起归档，供所有项目成员使用。

步骤二：静态代码分析

在完成源代码的开发以后，下面要进行的工作就是审视和测试代码。除了通过运行测试代码来检查功能之外，还能利用一些静态分析工具来快速、直接地 提高代码质量。静态代码分析工具并不需要运行代码，可以直接对Java文件和Class文件进行分析，通过一些检查条件的设置，快速找到代码中的错误和潜 在缺陷。现在的静态分析工具很多，有FindBugs、PMD、IBMRationalTool，等等。在这里，选择FindBugs作为静态代码分析工 具。FindBugs可以和日常开发工具Eclipse进行集成，在开发过程中，就可以方便的开始静态代码的检查。通过检查Class文件或者JAR文 件，将字节码和一组缺陷模式进行对比，来发现可能存在的代码问题。在Eclipse的开发环境中，用插件安装的方式安装了Findbugs后，在 Eclipse的配置选项中就会多出来FindBugs的配置选项。可以对自己的项目进行配置，选择需要的Detector检查代码。

图5.FindBugs的配置选项

设置好自己的规则后，在需要检查的代码文件夹上点击右键，就可以启动FindBugs检查。代码可以是一个项目，也可以只是几个文件。

图6.运行FindBugs

检查完毕后，会出现FindBugs视图，把所有检查的结果根据错误分组展示。点击结果里面的每一个错误，会自动打开对应的代码。当根据规则改 正了所有的错误，或者说潜在错误，这些代码也就通过了静态代码检查。FindBugs的检查结果可以是XML文件，也可以是文本文件，便于项目的集成管理 和检查保存。

图7.FindBugs检查结果

步骤三：单元测试

单元测试用例设计和评审

单元测试是软件开发过程中重要的质量保证环节，在此环节中，设计和评审对于保证整个单元测试过程的完整性和有效性来说十分重要。设计阶段需要具 体考虑要对哪些代码单元进行测试，被测单元之间的关系，测试策略，以及单元测试用例设计等，并最终输出《单元测试用例设计》文档，用来指导具体的单元测试 执行。在用例设计中，通过对代码单元输入和期待输出的定义来保证该单元的功能正确性，边界值的测试和异常测试非常重要。同时也配合测试用例和功能块的匹配 方法来衡量用例设计的完整性。

在用例设计完成之后，下一步的工作就是进行测试用例的评审。个人的理解和经验始终是有限的，用例评审可以借集体之力，对用例设计进入查漏补缺， 进一步保证测试用例的有效性。由于单元测试属于白盒测试范畴，它主要通过对代码的逻辑结构进行分析来设计测试用例，因此，评审员的选择最好以理解代码逻辑 结构为前提，如果评审员来自相关模块，还能够有效的发现模块相关性和依赖性所带来的问题。

模拟对象技术

在实际项目中，开发人员自己的代码往往需要和其他的代码模块或系统进行交互，但在测试的过程中，这些需要被调用的真实对象常常很难被实例化，或 者这些对象在某些情况下无法被用来测试，例如，真实对象的行为无法预测，真实对象的行为难以触发，或者真实对象的运行速度很慢。这时候，就需要使用模拟对 象技术(Mock)，利用一个模拟对象来模拟我们的代码所依赖的真实对象，来帮助完成测试，提高测试覆盖率，从而提高代码质量。模拟对象技术利用了在面向 接口的编程中，由于代码直接对接口进行调用，所以代码并不知道引用的是真实对象还是模拟对象，这样就可以顺利的完成对代码的测试，模拟技术有很多种，如 jMock，EasyMock，Mockito，PowerMock等等。其中Mockito消除了对期望行为的需求，避免了这些代码的大量初始化。

图8.Mockito示例

在模拟对象过程中，先模拟一个需要调用的List对象LinkedList，再设定这个对象的行为，当调用get(0)的时候，返 回”first”。这样，测试代码就可以利用这个对象来测试我们的功能代码，需要调用和返回值的时候，可以顺利的得到模拟对象的返回值。也需要对模拟对象 进行错误情况的模拟，保证代码对错误的处理的正确性。

测试覆盖率分析

为了衡量单元测试的质量和覆盖的范围，需要对单元测试的代码进行测试覆盖分析。常用的衡量测试覆盖率的指标主要有语句覆盖率、分支覆盖率、路径 覆盖率、条件覆盖率和方法覆盖率等。具体采用哪些指标可以根据项目的实际情况来定，以避免因过高的指标增加了代码开发人员的工作量而影响了项目整体的进 度。

EMMA是一款比较流行的开源Java测试覆盖率分析工具，支持类、方法、代码行、基本代码块等多种类型的测试覆盖率分析，支持将覆盖率分析结 果导出为多种格式的报告，并采用多种颜色来高亮显示不同的覆盖率状态。EclEmma是一款基于EMMA的Eclipse插件，方便在 EclipseIDE中进行测试覆盖率分析。如图9，在测试用例写好后，可以在右键点击测试类，选择CoverageAs->JUnitTest。

图9.运行测试覆盖分析

单元测试跑完后，Coverage视图中会显示所选择的测试的覆盖率。双击打开某一具体的类后，可以看到高亮显示的覆盖分析结果，如图10所 示。红色代表测试没有覆盖到该行，黄色表示部分覆盖，绿色的行表示该行在本次测试中被覆盖到。

图10.查看测试覆盖分析结果

在Coverage视图中可以通过点击鼠标右键将测试覆盖分析的结果导出成需要的格式，例如HTML。

图11.导出测试覆盖分析结果

图12显示了导出的report。

图12.测试覆盖分析报告

为了保证单元测试的有效性和质量，可以规定一个测试覆盖率的下限，例如所有的包和类的覆盖率必须达到80%以上。不过值得注意的是，不要单纯追 求高覆盖率，要同时注意测试用例的质量，如果测试用例本身就写的有错误，那么即使测试覆盖率很高也没有意义。

步骤四：持续集成

持续集成(ContinuousIntegration)是利用一系列的工具，方法和规则，做到快速的构建开发代码，自动的测试化，来提高开发 代码的效率和质量。利用自动构建工具，随时都能把提交的代码构建出来，提供一个可以测试使用的版本，让用户和开发人员同时看到相同的功能，尽早的发现问题 和错误，也可以尽快的得到测试人员和用户的反馈。

要做到持续集成，就要利用一系列工具，把开发过程中的重复工作自动化。搭建自动的构建服务器， 自动的进行单元测试和发布新版本，一个集成的服务器可以提供构建过程的结果报告，自动通知开发人员构建结果，并且保存历史数据。 IBMRationalTeamConcert(RTC)可以提供工作任务的管理，项目计划的安排，代码版本管理控制，自动构建可用版本，生成构建结果报 告。这些过程构成了项目的持续集成过程，其中，版本的自动构建和代码的自动单元测试是持续集成的关键过程，RTC在这些过程上提供了有力的支持。

自动构建

RTC提供了buildengine来负责构建build，首选，启动buildengine，并和RTC服务器建立了连接。再创建项目的 build定义。在这个定义中，需要设定编译哪些模块的代码，需要跳动哪个ANT文件来启动编译，和一些编译过程中的参数的设 定。当这些都准备好了，编译对于项目而言，就变成一个简单的事情。

可以看到，通过在build定义上，点击请求构建，就可以触发一次构建过程。选择需要的构建参数，这个过程就会在后台运行。每一个开发人员，做 了稍许的代码改变和提交，都可以触发新的构建过程，来保证我们代码的有效性。申请一个新的构建的过程如图13、图14所示。

图13.申请一个新的构建

图14.构建申请界面

当构建结束后。RTC服务器会提供构建结果报告。开发人员可以查询到这次构建的详细信息。

图15.构建结果

整个开发过程中，构建版本的过程应该是无数次的，通过每次构建，都可以得到当时代码的编译情况，并且可以得到一个可运行的软件版本。在构建定义 上，RTC支持设置构建计划。定时自动的触发一次构建。

图16.构建定义

自动单元测试

构建可以自动了，重点提高代码质量的单元测试呢？如果每一天的代码，每一个版本的代码，都已经通过了我们的单元测试，这样我们就能对代码的质量 有了基本的保证。在构建脚本的自动调用过程中，通过ANT的脚本，可以加上JUnit，EMMA，FindBugs的ANT脚本调用，每一次的构建，都可 以把这些检查工作自动的进行一遍测试。这些测试都要生成测试结果报告，RTC不能提供这些报告的展示，就可以利用Hudson这个开源工具，集成测试报告 来方便查阅。

图17.自动测试报告

步骤五：代码评审和重构

代码评审(CodeReview)是Java项目开发过程中的一个重要步骤，代码评审可以帮助发现静态代码分析过程中无法发现的一些问题，例如 代码的编写是否符合编码规范，代码在逻辑上或者功能上是否存在错误，代码在执行效率和性能上是否有需要改进的地方，代码的注释是否完整正确，代码是否存在 冗余和重复。代码评审还可以帮助新进入项目组的成员快速学习和了解项目，促进经验分享，同时也能保证项目成员的良好沟通。代码评审主要包括两种形式，同级 评审(PeerReview)和小组评审(GroupReview)。同级评审主要指项目成员间的互相评审，小组评审是指通过召开评审会议，项目成员一起 对项目代码进行评审。

为了提高代码评审的有效性和效率，可以借助一些外部工具，比较常用的代码评审工具有Jupiter和CodeStriker。Jupiter是 一款开源的Eclipse插件，允许成员将评审意见定位到真实代码的具体行，由于代码评审的结果以XML文件的形式保存，所以可以把结果提交到版本管理服务器进 行共享。图18显示了使用Jupiter进行代码评审的界面。

图18.Jupiter代码评审界面

在代码评审任务创建后，Jupiter将代码评审分成三个阶段，个人评审阶段(IndividualPhase)、团队评审阶段 (TeamPhase)和问题修复阶段(ReworkPhase)。在个人评审阶段，评审成员将发现的代码问题或者缺陷记录下来，每个问题都会作为一个记 录保存在评审表格中。在团队评审阶段，团队的全部或者部分成员会一起对个人评审阶段发现的问题进行定性，如果问题确实存在，就将该问题分配给某个成员去解 决，并在Jupiter中将该问题设置成相应的状态。在问题修复阶段，团队成员会修复属于自己的问题，并将相应的记录设置成已解决等正确的状态。

Codestriker是一款基于Web的常用代码评审工具，对代码的评审可以针对某一具体行，也可以针对整个代码文件，评审意见会被保存在数据库中。评审人员可以同时看到其他人的评论，代码作者也可以针对某一具体的评 论回复。Codestriker支持邮件通知，还可以同版本控制服务器进行集成，以跟踪和显示文件内容的改变。图19显示了Codestriker的界 面。

图19.Codestriker报告界面

在实践中对所有代码进行小组评审会比较费时，所以可以根据实际情况来挑选一些核心代码进行小组评审，或者在项目的前期安排较多的小组评审，等项 目组的成员对代码评审的标准和要求有较好的理解，进行代码评审的经验提高后，就可以逐渐减少小组评审的次数，从而达到大部分代码即使只进行同级评审也能保 证很好的质量。

通过代码评审发现的问题要通过代码重构及时解决掉，较小的不涉及多人代码的重构可以由项目成员自己借助Eclipse的重构功能完成，不同项目 成员写的实现相同功能的不同代码要通过讨论整合成公共的类或者方法。比较复杂的或者比较高层次的重构工作，例如整个项目层面的代码组织形式的改变需要由整 个项目组共同讨论完成。

结论

软件开发没有一成不变、万能通用的流程和方法，希望大家能从本文得到启发和收益，结合您的实际项目特点，实践以上步骤和方法，并加以完善和改 进，共同打造高效高质量的Java代码，为您的项目成功奠定坚实的基础。