极限编程的流程

名词的解释和相关内容:

用户故事

事实上用户故事是极限编程13个实践(请看文末第一篇参考文章)中的计划.

计划游戏的主要思想就是先快速地制定一份概要的计划，然后随着项目细节的不断清晰，再逐步完善这份计划。计划游戏产生的结果是一套用户故事及后续的一两次迭代的概要计划。

首先客户和开发人员坐在同一间屋子里，每个人都准备一支笔、一些用于记录用户故事的纸片，最好再准备一个白板，就可以开始了。

• 客户编写故事：由客户谈论系统应该完成什么功能，然后用通俗的自然语言，使用自己的语汇，将其写在卡片上，这也就是用户故事。
• 开发人员进行估算：首先客户按优先级将用户故事分成必须要有、希望有、如果有更好三类，然后开发人员对每个用户故事进行估算，先从高优先级开始估算。如果在估算的时候，感到有一些故事太大，不容易进行估算，或者是估算的结果超过 2人/周，那么就应该对其进行分解，拆成 2 个或者多个小故事。
• 确定迭代的周期：接下来就是确定本次迭代的时间周期，这可以根据实际的情况进行确定，不过最佳的迭代周期是 2~3 周。有了迭代的时间之后，再结合参与的开发人数，算出可以完成的工作量总数。然后根据估算的结果，与客户协商，挑出时间上够、优先级合适的用户故事组合，形成计划。

隐喻

相对而言，隐喻这一个最佳实践是最令人费解的。什么是隐喻呢？根据词典中的解释是：“一种语言的表达手段，它用来暗示字面意义不相似的事物之间的相似之处”。那么这在软件开发中又有什么用呢？总结而言，常常用于四个方面。

• 寻求共识：也就是鼓励开发人员在寻求问题共识时，可以借用一些沟通双方都比较熟悉的事物来做类比，从而帮助大家更好地理解解决方案的关键结构，也就是更好地理解系统是什么、能做什么。
• 发明共享词汇：通过隐喻，有助于提出一个用来表示对象、对象间的关系通用名称。例如，策略模式（用来表示可以实现多种不同策略的设计模式）、工厂模式（用来表示可以按需“生产”出所需类得设计模式）等。
• 创新的武器：有的时候，可以借助其他东西来找到解决问题的新途径。例如：“我们可以将工作流看做一个生产线”。
• 描述体系结构：体系结构是比较抽象的，引入隐喻能够大大减轻理解的复杂度。例如管道体系结构就是指两个构件之间通过一条传递消息的“管道”进行通信。

当然，如果能够找到合适的隐喻是十分快乐的，但并不是每种情况都可以找到恰当的隐喻，你也没有必要强求

代码编程

　　简单设计

• 简单的设计呢？XP 实践者们总结的具体、可操作的思考方法。
• 首先写测试代码：具体将在后面详细描述。
• 保持每个类只负责一件事：SRP（单一职责原则）是面向对象设计的基础原则之一。
• 使用 Demeter（迪米特）法则：迪米特法则，也称为 LoD 法则、最少知识原则。也就是指一个对象应当对其他对象尽可能少地了解。用隐喻的方法来解释的话就是“只与你直接的朋友通信”、“不要和陌生人说话”。
• 使用 CRC 卡片进行探索。

　　测试先行／测试驱动开发

　　当我第一次看到“测试先行”这个概念的时候，我的第一感觉就是不解，陷入了“程序都还没有写出来，测试什么呀？”的迷思。我开始天马行空地寻求相关的隐喻，终于找到了能够启发我的工匠，首先，我们来看看两个不同的工匠是如何工作的吧。

• 工匠一：先拉上一根水平线，砌每一块砖时，都与这跟水平线进行比较，使得每一块砖都保持水平。
• 工匠二：先将一排砖都砌完，然后再拉上一根水平线，看看哪些砖有问题，对有问题的砖进行适当的调整。

　　你会选择哪种工作方法呢？你一定会骂工匠二笨吧！这样多浪费时间呀！然而你自己想想，你平时在编写程序的时候又是怎么做的呢？我们就是按工匠二的方法在工作呀！甚至有时候比工匠二还笨，是整面墙都砌完了，直接进行“集成测试”，经常让整面的墙倒塌。看到这里，你还会觉得自己的方法高明吗？这个连工匠都明白的道理，自己却画地为牢呀。

　　不仅我们没有采用工匠一的工作方法，甚至有的时候程序员会以“开发工作太紧张”为理由，而忽略测试工作。但这样却导致了一个恶性循环，越是没有空编写测试程序，代码的效率与质量越差，花在找 Bug、解决 Bug 的时间也越来越多，实际产能大打降低。由于产能降低了，因此时间更紧张，压力更大。你想想，为什么不拉上一根水平线呢？难道，我们不能够将后面浪费的时间花在单元测试上，使得我们的程序一开始就更健壮，更加易于修改吗？不过，编写测试程序当然要比拉一条水平线难道多，所以我们需要引入“自动化测试工具”，免费的 xUnit 测试框架就是你最佳的选择。

　　重构

　　重构时一种对代码进行改进而不影响功能实现的技术，XP 需要开发人员在闻到代码的坏味道时，有重构代码的勇气。重构的目的是降低变化引发的风险，使得代码优化更加容易。通常重构发生在两种情况之下。

• 实现某个特性之前：尝试改变现有的代码结构，以使得实现新的特性更加容易。
• 实现某个特性之后：检查刚刚写完的代码后，认真检查一下，看是否能够进行简化。

　　在《重构》一书中，作者 Martin Fowler 提示我们：在考虑重构时，应该要养成编写并经常运行测试代码的习惯；要先编写代码，再进行重构；把每一次增加功能都当做一次重构的好时机；将每一个纠正错误当做一次重构的重要时机。同时，该书中也列出大量需要重构的情况和重构方法。

　　最后类似地，给还没有足够勇气进行重构的程序员打几剂强心针：

• XP 提倡集体代码所有制，因此你可以大胆地在任何需要修改的地方做改动。
• 由于在 XP 项目组中有完整的编码标准，因此在重构前无须重新定义格式。
• 在重构中遇到困难，和你结对编程的伙伴能够为你提供有效的帮助。
• 简单的设计，会给重构带来很大的帮助。
• 测试先行让你拥有了一个有效的检验器，随时运行一下就知道你重构的工作是否带来了影响。
• 由于 XP 在持续集成，因此你重构所带来的破坏很快就能够暴露，并且得以解决。

　　重构技术是对简单性设计的一个良好的补充，也是 XP 中重视“优质工作”的体现，这也是优秀的程序员必备的一项技能。

参考文章:

1.浅谈极限编程　　https://blog.csdn.net/qq_32867467/article/details/91348723

2.软件工程导论(第6版) 　张海藩、牟永敏 著 / 清华大学出版社

极限编程的流程

原文：https://www.cnblogs.com/adressian/p/11038485.html