论文-080-软件工程新技术—极限编程xp

论文-080-软件工程新技术—极限编程xp内容摘要：

Coach Pair 文档 Spike 其它 价值观 勇气 简单 交流 开发开发 集成测试 PairPramming 单元 测试 持续集成 验收测试 迭代 小规模发布 产品品 计划 评估 Onsite Customers 调控 风险 时间 价值 CRC 质量 持续集成 开发 轻量极 开发环境 简单 需求 OnSite Customers 项目 计划 其它 价值观 勇气 反馈 交流 系统 Simple Design Refactoring 做最简单的事情 让系统运行 System Metaphor 9 （七 ） XP 的十二 条规则 重构（ Refactoring） 重构是 对已经完成的代码进行改进的过程。 在不对代码的外部行为进行改动的情况下，对代码内部的结构进行优化。 重构让您将学到的知识加入到代码中，同时又不会破坏测试。 它使您的代码简练。 这意味着它可以存在相当长的时间为 以后的开发人员引入更少问题，并为他们指引正确的方向。 •在 Metaphor 指引下的重构，是为商业模型服务的。 不要把重构变成 不断的盲目精简代码。 •重构和编程前的计划型设计 (Planned Design)结合，使 XP 的简单设计可行有效。 •XP 提倡毫不留情的重构 (Refactor mercilessly)。 •任何人可 重构任何代码，前提是重构后的代码要通过 100%的测试之 后才能 被 Checkin。 •可以根据需要，将一个迭代的全部目标定为重构。 •不要太在意什么是最简单的设计 ,愿意在最后重构，比知道如何做简单的设计重要得多。 •XP 建议您应该编写可能运行的最简单的代码，但同时也建议您应该不断学习。 开发人员重构有两个重要时机：实 现特性之前和之后。 开发人员尝试确定更改现有代码是否可以让 新特性的开发更容易。 他们查看刚刚写好的代码，看是否有方法可以对它进行简化。 例如，如果他们认为有抽象的机会，就会进行重构来从具体实现中除去重复的代码 现场客户 (OnSite Customer) 要使功能最理想， XP 小组需要在现场有一位客户来明确素材，并做出重要的企业决策。 开发人员是不 许单独做这些事情的。 让客户随时在场可 以 消除开发人员等待决策时出现的瓶颈。 客户是 Team 成员，在开发现场和开发人员一起工作。 传统的客户任务一般是讲解需求，运行验收测试 ，接收发布的系统。 XP 新增加的任务： * 写 User Story * 评估 User Story 的商业优先级 * 为每个 User Story 定义验收测试 * 计划开发内容 * 调控开发过程 建立商业模型，把隐藏在客户需求下的原则传授给开发人员： * 程序员理解的是表象，而 不是本质； * 程序员分担任务的过程支解了对他们商业模型的理解； * 某些开发外包或分阶测试 重构 勇气 Team 集体 拥有代 码 合作 统一 规范 其它 价值观 反馈 简单 交流 态度 自信 品质 好胜 骄傲 迭代 计划 开发 编程 配置 管理 Simple Design 取舍 10 段开发 (例如增量、迭代等 )导致 “ 知识泄露 ”。 参加设计过程 ： * 和程序员一起找出 Metaphor，引 导 设计方向； * 在 Metaphor 的帮助下，定义更 有效更实际的功能测试，给程序员的设计制定了规范； * CRC 卡鼓励客户更多地参加设计过程。 我们发现让客户在现场可能 是 最好的一种情形，但这不是解决问题的唯一方案。 底线是客户必须随时在需要回答问题和根据企业价值为团队提供指示时有空。 如果客户并非在现场专职陪伴团队的情况下就能做到这些，那很好。 如果能和团队 呆 在一起，这会更方便，但只是建议而已。 系统 隐 喻 (Metaphor) 体系结构是做什么用的。 它提供了系统各种组件以及它们是如何交互 画面 ，可以让开发人员了解新的代码部分适合放在哪里。 XP 中的系统 隐 喻 与大多数方法称作的体系结构差不多。 隐 喻为团队提供了一致的画面，他们可以用它来描述现有系统的工作方式、新部件适合的位置，以及它们应该采取的形式。 “The system metaphor is a story that everyone customers, programmers, and managers can tell about how the system works.” — Kent Beck Team 将 Domain/SubDomain Model， Design/SubDesign Model 以及一些关键概念等等抽象化为比喻。 通过这些比喻，加强客户和程序员之间的相互理解，消化积累知识，指导设计开发的方向。 例： •Market — 发布 /浏览，价格洽谈，生成和履行合同； •电影后期制作 — 邮递 — 电影院播放电影。 •Metaphor 的形成过程，是客户建立并抽象商业模型和商业概念的过程，是程序员建立并抽象设计模型和设计概念的过程。 •Metaphor 使客户和程序员用共通的模型和语言进行交流 — “One Team, one language”。 •Metaphor 可以 帮助减少 “ 知识泄露 ” 和 “ 支解知识 ”。 •Metaphor 是设计过程的航标 —— 真正灵活有效的设计是针对商业原则的设计，而不是针对商业原则表现形式的设计，更不是脱离商业需求目的的学术设计。 •随着开发的继续， Team 会找到更好的 Metaphor。 这是知识细化、深化的结果，是 “ 持续学习 ”(Continuous learning) 的过程；是对商业模型和设计模型的持续重构。 简单设计 (Simple Design) XP 的诽谤者说该过程忽略了设计。 事实不是这样。 问题是重量型方法建议您做的不过是提前完成大部分琐 碎的设计任务。 这就象是拍一张静态的地平线的照片，静止不动，然后尝试画一张如何到达那里的完美的地图。 XP 说设计不应该在事物保持不变的前提下预先仓促进行。 XP 认为设计非常重要，因此应该是一个持续的事务。 我们总是先尝试使用能够工作的最简单的设计，然后随着现实的不断显现来更改它。 简单设计 —— Do the simplest thing that could possibly work； You aren’t going to need it(YAGNI)。 简单设计是符合以下条件的设计： * 运行所有测试 * 不包含重复代码 * 明确陈述程序员对所有代码的意图 * 包含尽可能最少的类和方法 对简单设计的需求并不是说所有设计都很小，也不表示它们是无足轻重的。 它们只不 过需要尽可能简单，但是仍能工 作。 不要包括不使用的额外特性 ,我们称这样的事物为 YAGNI 11 （ You Aren39。 t Going to Need It 您将不需要它）。 不要让 YAGNI 破 坏您成功的机会。 结 对编程 (Pair Programming) 风险会使大多数团队停滞不前 ， 减少风险的最佳方法是确保团队中的每个人都完全熟悉系统 的所有部件以及对系统的所有更改。 技术讲解和设计文档很有用，但对于大多数快节奏的项目，它们并不能很好且迅速地传播知识。 传播知识最有效的方法是让一个知道代码的人与不知道代码的人一起解决问题。 结 对 是两个人一起解决同一个编程问题。 使用 XP， 结 对的开发人员编写所有产品代码。 这种方式听上去好象缺乏效率。 Martin Fowler 说 ：“ 当人们说 结 对编程降低生产力时 ，我回答， ‘ 那是因为大多数耗费时间的编程部分是靠输入来完成的 ’”。 实际上， 结 对编程无论在经济还是其它方面都提供了许多好处： * 鼓励团队 * 提高生产力 * 减少风险 * 使团队生产效率更高 * 生成更好的代码 * 促使知识的传播 结对 是经理和团队减少风险并防止因更改而毁掉团队必须运用的最好的工具之一。 当团队成员结对时，所有设计决策和代码更改都至少由两个人完成。 通过让程序员结对，经理确保了更多人熟悉代码以及它经历的更改。 此外，两个人编写的代码总比一个人写的代码好。 两个人的智慧确实胜过一个人的，对于影响整个系统的设计决策更是如此。 研究显示 结 对编程确实 比单独编程更有效。 一周 40 小时 (40hour week) Kent Beck 说 ：“ 他希望每天早晨都感到有活力有激情，每天晚上都感到疲惫而满足 ”。 一周 40 小时工作可以让您做到 这一点。 确切的小时数并不重要，重要的是原则。 长时间地持续工作会扼杀工作绩效。 疲劳的开发 人员会犯更多错误，从长期来说，将比按正常时间表进行的开发慢得多。 一周 只 工作 40 小时 ， 体现了 XP 以人为本的价值观。 它 保证了程序员可以持续地完成任务。 即使开发人员可以在长时间很好工作，这也不意味着他们应该这样。 最终他们会厌倦，会离开他们的工作，或者产生影响他们工作绩效的非工作问题。 如果您打乱了人们的生活，将会尝到它所带来的 恶果。 加班并不是解决项目问题的答案。 实际上， 加班多导致开发效率和质量下降，简洁增加了开发成本， 它是更大问题的症状。 编码标准 (Coding Standards) XP 中的 编码标准 规定了 程序的风格，包括注释如何写，变量命名的规范，代码的格式等， 它是 Teamwork 的前提之一，是其它众多惯例和规则的前提之一。 拥有编码标准有两个目的： * 防止团队被一些例如事物没有以最大速度发展这种无关紧要的愚蠢争论搞得不知所措 * 它 可以 支持其它方法。 如果没有编码标准，重新划分代码会更加困难，按应当的频度 交换对更困难，快速前进也更困难。 目标应该是团队中没有人辨认得出是谁写的哪一部分代码。 以团队为单位对某一标准达成协议，然后遵守这一标准。 目标不是创建一个事无巨细的规则列表，而是提供将确保您的代码可以清晰交流的指导方针。 编码标准开始时应该很简单，然后根据团队经验逐步进化。 不要预先花费太多时间。 创建能够工作的最简单标准，然后逐步发展。 持续集成 (Continuous Integration) 经常进行代码集成可以帮助您避免集成梦魇。 XP 团队在一天中集成代码几次，每次都在所有单元测试对系统运行后执行。 持续集成是指不断地把完成的功能模块整合在一起。 目的在于不断获得客户反馈以及尽早发现 BUG。 传统方法工作方式如下：编写大量代码后执行一次大爆炸式的集成，然后花费相当长的时 12 间来改正问题。 这种笨拙的形式的确使项目速度减缓。 大爆炸式的集成 立即 给团队带来大量的 问题，并且这些问题通常都有几百种可能的原因。 如果经常 集成，任何特定集成失败的原因都会非常明显（以前运行过测试，因此错误一定是新事物犯下的）。 使用这种方法，当遇到问题时，可能的原因就相当有限。 修改起来更容易，花的时间少得多，使团队保持最快速度。 规划 策略 (Planning Game) 有些人 指责 “ XP 是一种美其名的剽窃， 是一群牛仔在没有任何规则的情况下将一个系统拼凑在一起 ”。 错。 XP 是为数不多的几种承认您在开始时不可能事事通晓的方法之一。 无论是用户还是开发人员都是随着项目的进展过程才逐步了解事物的。 只 有鼓励和信奉这种更改的方法才是有效 的 方法。 XP 留心更改 ， 它倾听所用的方法。 它是 一个由 Kent Beck 创造的概念。 这一方法背后的主要思想是迅速地制定粗略计划，然后随着事物的不断清晰来逐步完善。 规划策略的产物包括：一堆索引卡，每一张都包含一个 客户 素材，这些素材驱动项目的迭代；以及对下一两个发行版的粗略计划 ， 让这种形式的计划得以发挥作用的关键因素是让用户做企业决策，让开发小组做技术决策。 如果没有这一前提，整个过程就会土崩瓦解。 开发小组要决定： * 估计开发一个素材要花多长时间 * 使用各种技术选项所花费的成本 * 团队组织 * 每个素材的 “ 风险 ” * 迭代中素材开发的顺序（先开发风险最大的那一个可以减轻风险） 客户需要决定： * 范围（一个发行版的素材和每一次迭代的素材） * 发行日期 * 优先级（根据企业价值先开发哪些特性） 规划经 常发生。 这样，在客户或开发人员学习新事物的同时，就为他们调整计划提供了频繁机会。 小发行版 (Small Releases) 不断地发布可用的系统可以告诉客户你在做正确的事情。 客户使用发布的系统，可以保证 频繁地反馈和交流。 发行版应该尽可能地小，同时仍然提供足够的企业价值以证明它们值得。 发布过程应该尽可能地自动化。