• 常用的goal
• checkstyle:checkstyle
• 备注
• 可以用eclipse-cs编辑检查规则http://eclipse-cs.sourceforge.net/index.shtml
  

• surefire-report 生成单元测试报告
• 常用的goal
  
• surefire-report:report
  
• jdepend 生成包的度量报告
• 常用的goal
  
• jdepend:generate
  
• findbugs 检查潜在的缺陷
• 常用的goal
  
• findbugs:findbugs
  
• cobertura 生成测试覆盖率报告
• 常用的goal
  
• cobertura:cobertura
• 备注
• 直接从官方镜像下载的版本有个bug，不能正确生成报告（参见http://jira.codehaus.org/browse/MCOBERTURA-61）可以下载补丁后的jar替换本地repository的
• jdk1.4对应的补丁: http://dist.codehaus.org/mule/dependencies/maven2/cobertura/cobertura/1.8/cobertura-1.8.jar
• jdk5对应的补丁:http://www.artofsolving.com/files/m2/cobertura-1.8.jar
  

相信不只你我，大部分的人都比较认同敏捷化的过程，希望使过程变得敏捷。的确，这是个好东西，之前我也说过“敏捷过程是三赢的”这样的话。

我所关心的问题是“如何能够用好XP？”。

庄兄认为“汤的味道，不需要什么过程控制”，我也会认同。为什么？因为你我都是中国人。大部分中国人不会认为汤的味道需要什么过程控制。但是想想看，如果你在不同地方买到的肯德基炸鸡味道各异；同一批次生产的同型号的汽车形状各异；银行里取出来的一叠百元大钞大小不一，你不会觉得奇怪么或是有那么一点点愤怒么？

西方人（甚至学习西方的日本人）对品质的重视程度却完全不同。他们不允许肯德基炸鸡的味道有很大偏差（即便你觉得无所谓）；“2毫米工程”不允许整车的总装长度发生2毫米以上的偏差（即便你觉得无所谓）；百元大钞……（我想谁都不会无所谓）。

所以，一切质量都有标准，一切标准都应该被度量！这就是工程学的目标之一，为了实现更严格的质量标准，就需要过程控制和度量。

庄兄所说，用测试用例保证代码的质量其实还是采用了“测试用例”作为度量的标准。唯一的问题是：“如何确保测试用例的质量”。显然，我们不能把一把不直的尺子度量出来的结果作为可靠的参考依据。怎么解决呢？“结对编程”么？嗯，这是一个不错的方式，那么最终该信赖谁呢？是Pair中的A还是B呢？或者，是Leader么？那么又是谁提出的要求呢？是老板么？还是客户？政府？法规？市场？……问题没有终结了。

不要学习哲学家的方法，提出一层又一层无法解决的问题。我们是工程师，应该试图解决问题才对！解决问题的关键在于，XP同样需要标准！为了制定标准，必要的文档是不可以少的。而且，标准本身的质量是严苛的。因为，作为标准，他不可以含糊其辞、模棱两可。在标准的基础之上，我们才可以谈什么TDD、Pair Programming之类的实践。

回到争论的开端。我引用了林先生的话“UP是正楷；XP是草书。要先学好UP才能学好XP，先学XP会乱套。”我对这句话的理解如下：这句话并没有批判UP或是XP，只是指出了一个学习的顺序。我认为这句话是有实践依据的，因为UP强调的是一种经典的工程方法。软件工程本来就源于其他行业的工程实践经验。UP利用大量的文档对开发活动进行约束和记录。正是这种重量级的过程规范了规范了从PM到Coder的所有活动，有问题可以参照文档，看看自己应该怎么做。文档也可以作为日后评估这个过程的依据。随着整个团队和每个个人的经验不断积累，开发活动中的日常行为渐渐形成了一种职业习惯。然后可以通过对UP的配置，逐渐减少文档的使用量，一些没有必要的文档就可以省去，更具团队的实际能力调整过程。UP是可配置的，不必要的文档没有存在的理由，这一点UP和XP没有什么两样。当然，随着大家的职业习惯越来越好，经验越来越丰富，个人和团队就可以采用更敏捷更轻便的过程，逐渐过渡到XP上去。

反过来，如果一开始就没有详尽的文档，很多活动（比如设计、版本控制）往往会脱离控制，进入一种无序的、混乱的状态。没有文档可参考，就意味着很多问题只能问人，而不同人的回答可能各异，同一个人对同一个问题的两次回答也可能不同！当然，如果整个团队的工程素养和个体的职业习惯都比较好的情况下可能不会发生类似的情况。但是这种工程素养和职业习惯从哪里来，可能单靠的XP是不足以培养出来的。

“UP是正楷；XP是草书。要先学好UP才能学好XP，先学XP会乱套。”这句话表明了UP和XP在一定程度上是存在冲突的，并且提出了一条路线去降低和避免这个冲突。

再次需要强调的是庄兄所提到的“XP是一种思想”，这点我认同。但是我认为这个除了思想之外，还是一种“文化”。这种思想和文化也是出于软件工程多年来的实践，其中也不免有UP等其他过程。不能简单地认为“我们只要吸取历史的教训，提出新的思想和文化就不会再犯同样的错误了。”很多时候历史总是一次又一次地重演着。新的思想和文化如果不能被准确地理解和运用，它所带来的可能仍然是它原本想解决的问题。只有我们具备了引入这种文化的基础，才能把它变成自己的文化，否则这仍然是挂在嘴边行于表面的一种不求精髓只求模仿的伪文化、伪思想。这一点对于UP和XP的实践者来说没有什么两样。

举个例子，比如你做一锅汤：
今天你状态很好，做完后尝了尝，感觉很美味，你的家人尝了以后也有同感，喝完后感觉心情舒畅、意犹未尽。
隔了一个礼拜，你做同样的汤给家里人喝。做完后你尝了尝，感觉依然美味，盼望着得到家人的赏识，然而他们却说味道咸了点。你很奇怪，为什么同样自己尝过了，家里人却感觉不一样呢？是不是最近加班多了，休息不好，味觉不准了？
一个月过后，你要去国外出差，给家里请了个临时保姆。一天，他也做了这么个汤，做完后，他也尝了尝，感觉口味很不错，可是端上桌，家里人说这汤太辣了。原来这保姆才从湖南老家出来不久……

因此，只把焦点放在最后的产品上往往是不够的。需要对“做汤的过程”加以控制。所以工程界会比较关注过程的管理，在软件领域也称作“软件生命周期管理”。

再来看看UP和XP。它们都属于软件过程，只不过各有特色。

再拿刚才那个做汤的例子：
大家都听说过德国人的厨房像化学实验室，天平、计时器、量杯……装备齐全，再配上精确的菜谱，严谨的德国人能够确保不用尝那最后一口都做出口味基本一致的汤。
换了中国人，大部分人都不会模仿德国人做菜的方式。解决方案很简单，让你的太太和孩子都尝那最后一口，再根据反馈调整几次，同样能做出全家人满意的汤。

这个例子也许不太贴切，但是可以联想一下:德国人做汤倾向于UP;中国人做汤倾向于XP。

UP和XP最终目的都是为了保证产品的质量，不同的是，两个过程所强调的方法不同。我想，没有人会说“UP的目的在于变态地追求文档的完美”、“UP是为了要程序员学会写各种各样文档”……之类的话。同时，也没人会说“XP就是不要文档只要代码”、“XP就是要变态地追求完美的代码”……这样的话。

这些不正确的看法，只是人们对于这两种过程的误解。或许是来自于开发人员和项目经理的那些“不堪回首的经历”。

“UP害惨了整个软件行业，让开发人员没完没了地写文档而忽略了代码，XP才是王道”这样的话，我不敢苟同，仍然有很多企业使用着UP这样的重型软件工程，就好比德国人依然喜欢把厨房弄得像个实验室。

XP固然是个好东西。但是，不知道大多数人对于XP的热衷是出于对XP文化的理解，还是国人惯有的“一窝蜂”似的行为。不晓得一个“能够熟练阅读代码的Leader”是不是能够真正运用好XP，确保他的团队能够尽可能少地出现"Over engineering"这种违背Agile精神的东西，或是能够让他的团队保证“每周只工作40小时”这样的基本实践？

对于不同的技术和过程，应该给予冷静的分析和慎重的选择。每个过程和技术都不能以“正确”或“不正确”来定性，只能以“合适”和“不合适”来定性。因为正确或不正确是要严格证明的，而合适不合适是来源于工程实践的结果。所以，COBOL依然在金融领域起着举足轻重的作用，科学家们仍不忘Fortran，汇编和C仍然健在……

另外不得不提的是文化上的差异。为什么很多时候，我们学习国外的先进技术，购买了整套生产线，引进了全套图纸，请国外专家做了详细的全程化培训，国人生产出的产品品质依然不如国外原产的？这是每个中国人都应该思考的问题……

老师曾这么说。最近，对这句话有了深刻的体会。

软件过程是一个以人为中心的活动。人是项目中最难确定和控制的因素。休息的质量、情绪的起伏都会影响整个活动。为了尽可能地约束这种个体的不确定行为和减少开发过程中不必要的误会。"UP"采用了大量的文档来对整个开发过程进行控制。这些文档主要分为以下几类：

• 计划文档——项目的开发计划、迭代计划、测试计划等。
• 技术文档——项目的设计文档、某个操作的说明文档等。
• 记录文档——日常的会议纪要、每日进度反馈、评估报告等。

文档成了UP活动的主要部分。在UP中，往往大量的资源用于文档的制作。这些文档的目的是为了尽可能减少不必要的沟通成本和误会，也为了在发生问题的时候能够尽快确定原因找到解决方法。

而正是因为如此繁重的资源消耗，导致真正的设计和代码只占到了总开销的很少部分。这对很多人来说不可理解，甚至觉得本末倒置。于是很多敏捷方法诞生了，最具代表性也是对UP思想最具颠覆性的就属XP了。

对外，XP以快速的反应速度来响应客户的需求；对内，XP以高质量的代码和设计来确保尽可能不产生不必要的文档和资源开销。

从表面上看，在当今，XP确实是一种非常理想的开发过程。

但是，从没有过程到XP往往会非常失败。这是为什么？问题的关键还在于人。

• 无过程-->UP -->XP

UP利用文档来约束和规范人们的开发活动。当一个没有经验的团队经历UP后，就等于把性格各异、习惯差别不同的人统一成了“相对较一致的开发人员”。

他们有一致的编码习惯，有共同的用语，有严格的规则。随着经验的积累，这个团队间的默契越来越高。此时，如果过程由UP向XP切换，付出的代价就会相对较低。

• 无过程-->XP-->UP

XP主张快速反应。如果一个没有经验的团队在一开始就尝试XP，那么后果可能是惨痛的。因为一个没有经验的团队其成员间的相互了解颇少，对于一件事，往往十个人有十种想法。当缺少文档约束时，在以代码和设计为中心的活动中，成员之间往往因为水平的参差不齐导致无休止的讨论甚至争论，代码被不必要地频繁改动。这是因为，在团队建设早期，成员之间往往连最基本的尊重和信任都不存在。 这种无意义的活动往往会严重影响项目的正常进行。

所以，学习和应用过程不仅仅是个体的事，而是整个团队的事。只有当团队采用严格文档化的过程并且经过磨合后，才能渐渐向轻量级的过程迁移，逐渐将不必要的文档删减掉，采用更灵活的过程。但是，此时并不是“没有文档”而是“心中有文档”。