第12章软件工程原理与应用

图12.1 传统开发方式很难应对需求变化
图12.2 极限编程立足于降低变化带来的损耗
一套软件开发方法是由一系列与开发相关的规则。重量级的开发方法严 格定义了许多的规则、流程和相关的文档工作，一般适合于大型的软件开发。 而XP这样的轻量级开发方法，其规则和文档相对较少，流程更加灵活，实施 起来相对较容易。 因为极限编程还很年轻，国内对它的术语没有统一的译名，为了方便大 家今后查阅这方面的资料，本章将列出每个术语的英文名。按照极限编程的 行业惯例，对一些不方便翻译的术语，比如user story，直接使用其英文叫 法，对一些有了固定中文译名的术语，比如“重构”(refactor)则主要使用其 中文叫法。
12.2.6
发布
当我们就有了一个开发计划，每经过一个开发周期（Iteration），软件就发布 一次。在一个开发周期内，开发人员要求客户选择最有价值的User Story作为 未来一两个星期的开发内容。 第一个开发周期完成后，提交给客户的系统虽然 不是最终的产品，但它已经实现了几个客户认为是最重要的Story，开发人员将 逐步在其基础上增加新的模块。在发布前软件都经过单元测试和集成测试，因 此虽然软件并不完备，但是客户如果愿意的话，可以真正使用它。
12.2 极限编程的软件开发模式
12.2.1工作环境 工作环境 每个参加项目开发的人都将担任一个角色（项目经理、项目监督人等等）并履行相应 的权利和义务。所有的人都在同一个开放的开发环境中工作，最好是所有人在同一个大房 子中工作。每天早晨，所有人一起站着开个短会。墙上有黑板，随时随地都可以在黑板上 讨论问题。所有的Story卡、CRC卡等都贴在墙上。 极限编程强调一周40小时工作制，不 加班。
第12章 极限编程
12.1 极限编程概述 极限编程（ 极限编程（Extreme Programming，简称XP）由Kent Beck在1996年最先提出并 在全球大量应用的一种新型软件工程模型。 之所以另辟一章单独讲授极限编程，是因为极限编程是一种轻量级的、灵巧的、 简单的软件工程方法，适合12人以下的小型开发团队。它的主要目标在于面对商业环 境作出了务实的选择，力求降低需求变更而带来的成本，提高软件的客户满意度。 在传统系统开发方法中，系统需求是在项目开发的开始阶段就确定下来，并在之 后的开发过程中保持不变的。这意味着项目开发进入到之后的阶段时出现的需求变 更——这样的需求变更在国内目前的商业环境中是不可避免的——将导致开发成本急 速增加
12.2.5 测试
XP提倡在开始写程序之前先写单元测试。开发人员应该经常把开发好的模块整合到 一起 （Continuous Integration），每次整合后都要运行单元测试；做任何的代码复 核和修改，都要运行单元测试；发现了BUG，就要增加相应的测试（因此XP方法不 需要BUG数据库）。除了单元测试之外，还有整合测试，功能测试、负荷测试和系 统测试等。所有这些测试，是XP开发过程中最重要的文档之一，也是最终交付给用 户的内容之一。 在极限编程中，测试是非常重要的一个环节。它首先要求在编程之前先写好测试。 其目的是为了提高软件的可测试性。软件设计如果没能够考虑软件的可测试性，那 么测试的成本就会升高，软件质量随之下降。 另外是为了提高程序的可测试性。有时候，单元测试或是组件测试是很难进行的。 例如，对于一个实现企业流程的组件，之间涉及到大量的状态、事件、分支选择等 等因素。对这样的组件进行组件测试的代价是非常高的。因此，事先写测试，可以 让代码的结构便于测试。从而降低测试成本，软件质量因此提高。 以Junit为代表的xUnit测试框架是目前广泛应用的开源测试软件。它是一个回归测试 框架（regression testing framework）。这是一种白盒测试，测试者必须知道被测 试的软件如何完成功能和完成什么样的功能。它还可以作自动测试。
User Story这个方法有以下几个好处：
①最好的需求就是用户自己写的需求，软件开发人员替用户写需求，容易曲解用户 的意思。用户自己写的需求最大地体现了用户的利益。 ②设计立足于要解决的现实事务，而不是立足于计算机模型。软件开发人员总是免 不了会站在计算机的角度看问题，User Story方法从根本上改变了这一点。 ③用户更重视全局，重视真正重要的部分。用户可以深度介入需求分析，在开发过 程中就不断调整开发的目标，防止交货后才发现问题，带来很大的修改成本。 ④可作为评估软件是否成功的依据。 ⑤为用户竖立开发成本的概念。用户决定哪些部分最重要，哪些先开发，哪些部分 因为成本的关系，可以舍弃。
12.2.4 编程
成对编程（Pair Programming）是极限编程的一大特色，两个人一起使用 同一个屏幕，同一个键盘，写同一段程序。他们并不是轮换休息，而是一 个扮演司机，一个扮演导航员。比如，当一个程序员在写单元测试的时候， 另外一个就思考，怎样的代码可以满足这个测试。
成对编程的好处：
①更好的纪律：成对编程可以提高纪律性，防止长时间的发呆和“不务正业”。 ②更好的代码：两个人一起思考同一段程序，容易写出更优质的代码。极限编 程不但要求“司机”和“导航员”互换，还要求各个双人小组之间互相交换。 这样，有很多人会参与同一段代码的编写，不但可以显著提高代码的可读性， 当一对程序员卡壳的时候，还能迅速获得其他程序员的帮助。 ③更流畅的工作：一个人编程的时候，工作一旦被打断，思路也被打断，总是 需要花一些额外的时间才能继续刚才的思路。而两个人编程，另一个人可以立 刻接替上去。另外，一个人编程调试，当错误比较多的时候，很容易忘记忘记 错误代码之间的联系，忘记自己刚刚做了什么，正打算干什么。重新找回思路 需要浪费时间，而且使信心受挫。 ④分享： Pair Programming很容易使得整个团队很方便地分享编程经验。根据 国内一些XP实践先驱的经验看，这种模式使团队中经验不足的初级程序员获益 匪浅。没有任何一种学习方法，能够像极限编程一样，让一个初级程序员跟高 级程序员在一起思考，一起写代码，一起测试，一起做代码回顾（code review），接受手把手的指点。 另外，代码所有权归于整个开发队伍 （Collective Code Ownership）。程序员 在写程序和重整优化程序的时候，都要严格遵守编程规范。任何人都可以修改 其他人写的程序，修改后要确定新程序能通过单元测试。
12.2.3 设计
XP提倡简单设计（Simple Design），用最简单的办法实现每个小 需求。这些设计只要能满足系统和客户在当下的需求就可以了， 不需要考虑将来可能的变化。在XP中，没有那种传统开发模式中 一次性的、针对所有需求的总体设计。整个设计过程包括在整个 螺旋式发展的项目中。 在极限编程中有个计划游戏（Plan game Plan game）的概念。计划，往往 都是很多软件组织的一块心病。所有人都知道计划的重要性，没 有计划，软件过程无从遵循；可是计划赶不上变化。软件过程又 常常偏离计划。XP的态度是：与其在一开始就费时耗力地制定一 堆不切实际的计划，倒不如花费少量的精力做一个简单的计划， 然后在随后的软件过程中不断的进行调整。真正要实现这种“不 断调整”还是比较困难的，因此推荐大家在开发的时候使用面向 对象技术。在开发的时候先关注接口再不关注具体的实现。使用 “设计模式”调整内部结构却不改变接口。
User Story也有弊端。那些故事缺乏格式，各人的文学描述能力有差异，关键信息可能没有被 重点表达出来。关键流程可能被忽略。合法的特例可能被遗忘。对此，国内的一位XP先驱林星提出 采用use case(用例)技术。用例技术保持了需求的简单原则，它的形式和User Story非常的相似，但 是用例具有自己的格式，虽然这个格式也是可以任意定义的。用例的重点是表示系统的行为。用例 表示的内容和User Story并没有太大的差别，但用例比较强调格式。 CRC卡片是一组标准的索引卡片。每一张卡片被分为三个部分，分别是类的名称，类的职责， 以及该类的合作者。类是一类相似对象的抽象，职责是该类所知道的或要去做的，合作者是另外一 个与该类有交互的类。在需求建模过程中，CRC模型用在概念建模中，用来揭示某一领域内的概念 和它们之间高层的关系。 比如：一个出纳员类的卡片，类名称就叫出纳员，类的职责就是收钱、发钱，类的合作者就是 会计类和财务主管类。 可以看出，CRC卡片是立足于计算机语言的，而User Story则是立足现实世界的。一般来说，一 个User Story包括的CRC卡片不应该大于10个，否则就说明那个User Story太长了，应该分解。
12.3
重整和优化Байду номын сангаас
因为XP迭代开发的特点，重整和优化显得极其 重要。
12.3.1 重构可以达到的目标
1．改进软件设计 重构和设计是相辅相成的，它和设计彼此互补。有了重构，你仍然必须做预先的 设计，但是不必是最优的设计，只需要一个合理的解决方案就够了，如果没有重 构、程序设计会逐渐腐败变质，愈来愈像断线的风筝，脱缰的野马无法控制。重 构其实就是整理代码，让所有带着发散倾向的代码回归本位。 2．使代码更易为人所理解 Martin Flower说过"任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类 容易理解的程序才是优秀的程序员。"如果代码不能为人所理解，那么今后的维护 将十分困难。 3．帮助发现隐藏的代码缺陷 孔子说过：温故而知新。重构代码可以加深理解原先所写的代码。通过重构代码 可以加深对原设计的理解，发现其中的问题和隐患，构建出更好的代码。 4．从长远来看，有助于提高编程效率 当你发现解决一个问题变得异常复杂时，往往不是问题本身造成的，而是你用错 了方法，拙劣的设计往往导致臃肿的编码。
12.2.2需求分析 需求分析 客户被纳入项目开发队伍。由于客户不具备计算机专业知识，无法用专业语言明 确描述需求。所以开发人员和客户一起，用讲故事的方式把需求表达出来。这种故 事被称为User Story。因为有很多需求，所以有很多的User Story，开发人员根据经 验，把这些User Story组合或者分解，最终记录在一些叫做Story Card的小卡片上。 这些User Story将陆续被程序员们在各个小的周期（Iteration）开发。这个周期通 常不超过3个星期。 因为这个Iteration很短，所以不可能一次就实现所有的User Story. User Story按照下面的原则来确定优先级:客户来指定各个User Story的商业价值， 价值高的先开发。开发人员确定每个User Story的开发风险，风险高的将被优先开发。