敏捷开发学习总结(4)：极限编程(XP)学习笔记

极限编程(XP)有哪些实践方法？

1) 短期的迭代目标：

传统的开发方法，整个软件开发完成后才 发布，周期长所以收到客户反馈的时机晚。
XP的做法是按照需求的优先级，持续制定短期的开发目标（或小版本），完成一个小周期就发布一次，尽早取 得客户的反馈。

2) 简单设计：

关于设计，传统的开发方法中常犯的错误有：
a) 进行过多的预先设计，并认为越详细越好，并且极度依赖于非常详细的文档制品，从而使得开发过程极其繁重，拖慢团队响应速度，这时如何有需求的变动，修改的 代价很大。
b) 过多地假设未来的需求，从而将未来的需求纳入设计的考虑范围中，导致增加了设计的复杂性，增加工作量，且不易于理解和维护。
c) 程序员学会了一种新的设计方法，急于应用到开发中，也常常导致设计过度，例如滥用设计模式、OOD等。
d) 等等

XP不推荐对未来需求进行过多的预先设计，原因是:
a) 为了未来需求所进行的设计会使设计变得复杂
b)有时明天 用户会调整或取消掉需求
c)有时过一段时间你掌握了更好的设计方法，b和c这两 点会使开发团队花了时间和精力但是却没有产生效益。


3) 测试驱动开发：

传统的开发中，常存在一个问题是，程序员编码完成后，要等到交给测试组测试时，才发现有很多问题，如异常情况未处理、边 界条件未检查、某些不常用的特性未开发等。
测试驱动开发要求在开发之前，先写测试用例和测试代码，只有所有测试用例通过了，才认为测试完成，其好 处不言而喻，但测试驱动开发一般比较难以掌握，项目又比较急，倒可以考虑先用一个功能与特性的check list来折衷一下，即在开发工作开始之前，安排下去的每个开发任务按功能或者特性用excel整理一份验收表格，用它用驱动开发，开发完成后，用它来检 查是否覆盖了功能，但是，一些异常情况和边界条件的检查，仍需要依靠防御式编程及单元测试来进行。


4) 重构：
传统的开 发中，管理人员常常认为重构是返工从而惧怕听到重构一词，从而使得程序员缺少重构的勇气。


5) 结对编程：

不知 道在国内有多少公司有应用结对编程，如果你跟你老板说，结对编码就是两个开发人员只用一台电脑，一人编程时另一个人在旁边看着，他可能会认为你是不是疯了 :)，
但是结对编程在培养新人时的确是一种不错的方法，不实施结对编程，可以在培养新人时，适当地增加和新人一起坐在电脑面前的时间，在新人面 前手把手边解说边编写代码或者debug ，这样，新人可以从资深人员的编程过程中吸收到一些良好的编程习惯或者技巧，从而尽快可以上手。
传统开 发常通过code review的方式来提出代码中存在的问题，新人根据review report来修改代码，这种文档交流的方式缺乏互动，培训效果不是太好。

6) 代码所有权：

传统的开发中，一般将一个 个的开发任务分派给个人，个人所负责的模块需要修改或者fix bug时都由他自已来负责，这种做法可能是为了更好的管理，但有如下缺点：
a) 程序员会认为，别人通常不会来阅读自已的代码，因此对于提高代码可读性、可理解性积极性不高。
b) 每个人专注于自已的领域，不利于对整个项目整个系统的理解，也不利于团队技能的提升。

XP中的代码所有权意指代码所有权属于整个团队所有 人，每个人都可以修改任意位置的代码，其好处是：
a) 最大可能地达到知识共享；
b) 由于代码对所有人的修改开放，程序员自然而然地加强代码的可读性、可理解性，从而改进代码质量;
c) 当发现某些模块阻碍你前进的脚步时，你自已就可以扫清障碍，而不是等别人先修改你再继续；
d) 资浅的程序员容易产出品质不佳的代码，好的代码时间长了也会腐化，因此，所有人都有责任发现并重构已腐化、或质量不佳的代码;

传统开发团 队通过code review，让资浅人员根据review report慢呑呑地修改代码的方法可以灵活变通一下，当发现资浅人员的代码设计不好而影响到其他人的进度时，资深人员为什么不直接修改该资浅人员的代码 呢？

7) 持续集成：

尽早地集成团队各个成员的开发成果，使团队成员在设计理解上保持一致。
大部分的项目都有使 用cvs,svn等源 代码版本管理工具，这些工具可以方便地进行代码整合，但是问题在于，大部分的程序员都不太注意及时将自已的代码更新到代码仓库，原因有 1) 程序员想等到自已负责的功能开发完成后再提交到代码仓库; 2) 对自已的代码没有信心；3) 提交代码后要重新编译整个工程，费时间; 
我个 人的习惯是:
a) 尽早将自已的代码提交到代码仓库，提交后重新check out并编译整个工程，确否你的代码与其它队友的代码整合没有问题l
b) 对于单元测试代码或调试代码，我个人也建议在提交之前不要删除，而是用编译宏的方式不编译该部分的代码即可，避免日后仍需要这部分的代码;
c) 现在的源代码版本管理工具功能都非常强大了，所以对提交代码不要有过多的担心;
d) 尽量每天重新check out并编译整个工程，保持新鲜。


还 有其它一些实践方法没有在上面列出，如隐喻、编码标准、每周工作40小时和现场客户。



极限编程的4大基本原则：

1) 沟通

程序员不愿意把设计告诉别人；
程序员不向客户询问该问的问题（需求模糊不清时，常常猜测而不是去澄清）；
程序员常 常不主动向管理人员报告坏消息，原因是怕迁怒于管理人员；
程序员有时会把客户的话当耳边风；
所以，管理人员需要积极询问去了解程序员的工 作情况，
程序员、客户与管理人员必须积级地沟通。
传统开发用各种形形式式的文档来进行知识共享，而XP推荐用面对面沟通、结对编程、代码所有权的方式来达到团队之间的知 识共享；
传统开发通过 编写详细设计文档来指导代码的编写及后期维护，而XP则将代码视为“文档”，或将设计文档插入代码（自说明文档）的方式来保持代码与文档之间的同步问题；


2） 简单

程序复杂的原因之一是为未来的需求进行了过多的设计，极限编程实践不推荐对未来需求进行过多的预先设计，原因是:
a) 为了未来需求所进行的设计会使设计变得复杂
b) 有时明天用户会调整或取消掉需求
c) 有时过一段时间你掌握了更好的设计方法，b和c这两 点会使开发团队花了时间和精力但是却没有产生效益。
这一点与传统开发可能会有所有冲突。

简 单的设计除了可以节约开发成本，也降低了沟通的成本和维护的成本。


3) 反馈

及时向主管、客户反馈开发进度及遇 到的问题；
及时、尽早测试你代码，从而及时从系统中得到反馈；
只相信测试结果，在测试切实通过之前，不能盲目乐观；

4) 勇气

当你发现原有的代码结构混乱，且你认为你找到了更好的设计方法时，要有重构代码的勇气，
当你发现重构代码仍不能解决混乱状 况时，要有放弃原有的代码，重新编写代码的勇气。