软件工程原理与应用.pptVIP

12.2.3 设计 XP提倡简单设计（Simple Design），用最简单的办法实现每个小需求。这些设计只要能满足系统和客户在当下的需求就可以了，不需要考虑将来可能的变化。在XP中，没有那种传统开发模式中一次性的、针对所有需求的总体设计。整个设计过程包括在整个螺旋式发展的项目中。 在极限编程中有个计划游戏（Plan game）的概念。计划，往往都是很多软件组织的一块心病。所有人都知道计划的重要性，没有计划，软件过程无从遵循；可是计划赶不上变化。软件过程又常常偏离计划。XP的态度是：与其在一开始就费时耗力地制定一堆不切实际的计划，倒不如花费少量的精力做一个简单的计划，然后在随后的软件过程中不断的进行调整。真正要实现这种“不断调整”还是比较困难的，因此推荐大家在开发的时候使用面向对象技术。在开发的时候先关注接口再不关注具体的实现。使用“设计模式”调整内部结构却不改变接口。 系统比喻 （System Metaphor）是指虽然没有一个自上而下的设计过程，但是开发出来的类总是必须以某种方式结合在一起，形成一个完整的系统。XP要求集体拥有代码所有权，那么就必须让所有人都明白整个系统是怎么回事，而不是像从前那样，只有系统分析员知道整个系统的规划方案。了解整个系统不是一件容易的事情，况且团队中还有客户，他们是非专业人员，因此，以比喻的方式描述整个系统的功能是唯一现实的做法。 在XP实践中，人们发现，找到合适的比喻非常困难。因此有个替代做法――公共词汇表。如果找不到比喻，那就用类本身的名字来称呼他们。如果有一个词汇能比喻他们，那就把那个词写下来，放在公共词汇表中，以便所有的人都知道它其实是指什么。 因此在XP中，软件重构（Refactor）显得尤其重要，在重构的过程中，XP要求不断运行单元测试和功能测试，保证经过重整和优化后的系统仍然符合所有需求。重构就是努力优化代码，减少程序和设计中的重复部分，增强程序和设计的可重用性，完善程序的结构。重构是软件工程中最重要的概念之一。在极限编程中，强调把重构做到极致，应该随时随地、尽可能地进行重构，毫不留情地改进程序。 从具体开发的角度来看，XP是由测试驱动开发（Test Driven Development）。每个开发周期都有很多相应的单元测试（Unit Test）。刚开始，因为什么都没有实现，所以所有的单元测试都是失败的；随着一个个小的需求模块的完成，通过的单元测试也越来越多。通过这种方式，客户和开发人员都很容易检验，是否履行了对客户的承诺。 12.2.4 编程 成对编程（Pair Programming）是极限编程的一大特色，两个人一起使用同一个屏幕，同一个键盘，写同一段程序。他们并不是轮换休息，而是一个扮演司机，一个扮演导航员。比如，当一个程序员在写单元测试的时候，另外一个就思考，怎样的代码可以满足这个测试。 成对编程的好处： ①更好的纪律：成对编程可以提高纪律性，防止长时间的发呆和“不务正业”。 ②更好的代码：两个人一起思考同一段程序，容易写出更优质的代码。极限编程不但要求“司机”和“导航员”互换，还要求各个双人小组之间互相交换。这样，有很多人会参与同一段代码的编写，不但可以显著提高代码的可读性，当一对程序员卡壳的时候，还能迅速获得其他程序员的帮助。 ③更流畅的工作：一个人编程的时候，工作一旦被打断，思路也被打断，总是需要花一些额外的时间才能继续刚才的思路。而两个人编程，另一个人可以立刻接替上去。另外，一个人编程调试，当错误比较多的时候，很容易忘记忘记错误代码之间的联系，忘记自己刚刚做了什么，正打算干什么。重新找回思路需要浪费时间，而且使信心受挫。 ④分享： Pair Programming很容易使得整个团队很方便地分享编程经验。根据国内一些XP实践先驱的经验看，这种模式使团队中经验不足的初级程序员获益匪浅。没有任何一种学习方法，能够像极限编程一样，让一个初级程序员跟高级程序员在一起思考，一起写代码，一起测试，一起做代码回顾（code review），接受手把手的指点。 另外，代码所有权归于整个开发队伍 （Collective Code Ownership）。程序员在写程序和重整优化程序的时候，都要严格遵守编程规范。任何人都可以修改其他人写的程序，修改后要确定新程序能通过单元测试。 12.2.5 测试 XP提倡在开始写程序之前先写单元测试。开发人员应该经常把开发好的模块整合到一起 （Continuous Integration），每次整合后都要运行单元测试；做任何的代码复核和修改，都要运行单元测试；发现了BUG，就要增加相应的测试（因此XP方法不需要BUG数据库）。除了单元测试之外，还有整合测试，功能测试、负荷测试和系统测试等。所有这些测试，是XP开发过程中