极限编程只考虑当前的需求

① 软件工程相关基础问题

浅论软件工程
软件工程 (Software Engineering，简称为SE)是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及到程序设计语言，数据库，软件开发工具，系统平台，标准，设计模式等方面。
在现代社会中，软件应用于多个方面。典型的软件比如有电子邮件，嵌入式系统，人机界面，办公套件，操作系统，编译器，数据库，游戏等。同时，各个行业几乎都有计算机软件的应用，比如工业，农业，银行，航空，政府部门等。这些应用促进了经济和社会的发展，使得人们的工作更加高效，同时提高了生活质量。
软件工程师是对应用软件创造软件的人们的统称，软件工程师按照所处的领域不同可以分为系统分析员，软件设计师，系统架构师，程序员，测试员等等。人们也常常用程序员来泛指各种软件工程师。
软件工程的主要课程：
外语、高等数学、线性代数、高等代数、电子技术基础、离散数学、计算机引论（C语言）、数据结构、C++程序设计、汇编语言程序设计、算法设计与分析、计算机组成原理与体系结构、数据库系统、计算机网络、软件工程、软件测试技术、软件需求与项目管理、软件设计实例分析、CMM/ISO9000等。
软件工程(SoftWare Engineering)的框架可概括为：目标、过程和原则。
(1)软件工程目标：生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型及工程方法选取的约束。
(2)软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程，还有管理过程、支持过程、培训过程等。
(3)软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。
[编辑本段]软件工程的定义
软件工程一直以来都缺乏一个统一的定义，很多学者、组织机构都分别给出了自己的定义：
（1）。Barry Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。
（2）。IEEE在软件工程术语汇编中的定义：软件工程是：1.将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；2.在1中所述方法的研究
（3）。Fritz Bauer在NATO会议上给出的定义：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。
目前比较认可的一种定义认为：软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。
（4）。《计算机科学技术网络全书》中的定义：软件工程是应用计算机科学、数学及管理科学等原理，开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本。其中，计算机科学、数学用于构建模型与算法，工程科学用于制定规范、设计范型(paradigm)、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等管理。
[编辑本段]软件工程学的内容
软件工程学的主要内容是软件开发技术和软件工程管理．
软件开发技术包含软件工程方法学、软件工具和软件开发环境；软件工程管理学包含软件工程经济学和软件管理学。
[编辑本段]软件工程基本原理
着名软件工程专家B.Boehm综合有关专家和学者的意见并总结了多年来开发软件的经验，于1983年在一篇论文中提出了软件工程的七条基本原理。Boehm
（1）用分阶段的生存周期计划进行严格的管理。
（2）坚持进行阶段评审。
（3）实行严格的产品控制。
（4）采用现代程序设计技术。
（5）软件工程结果应能清楚地审查。
（6）开发小组的人员应该少而精。
（7）承认不断改进软件工程实践的必要性。
B.Boehm指出，遵循前六条基本原理，能够实现软件的工程化生产；按照第七条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。
软件工程(SoftWare Engineering)的框架可概括为：目标、过程和原则。
(1)软件工程目标：生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型及工程方法选取的约束。
(2)软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程，还有管理过程、支持过程、培训过程等。
(3)软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则
[编辑本段]软件工程必须遵循什么原则
围绕工程设计、工程支持以及工程管理已提出了以下四条基本原则：
(1)选取适宜的开发模型
该原则与系统设计有关。在系统设计中，软件需求、硬件需求以及其它因素间是相互制约和影响的，经常需要权衡。因此，必需认识需求定义的易变性，采用适当的开发模型，保证软件产品满足用户的要求。
(2)采用合适的设计方法
在软件设计中，通常需要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合适的设计方法有助于这些特征的实现，以达到软件工程的目标。
(3)提供高质量的工程支撑
工欲善其事，必先利其器。在软件工程中，软件工具与环境对软件过程的支持颇为重要。软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。
(4)重视软件工程的管理
软件工程的管理直接影响可用资源的有效利用，生产满足目标的软件产品以及提高软件组织的生产能力等问题。因此，仅当软件过程予以有效管理时，才能实现有效的软件工程。
软件工程是指导计算机软件开发和维护的工程学科。
采用工程的概念、原理、 技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够 得到的最好的技术方法结合起来，这就是软件工程。
软件工程强调使用生存周期方法学和各种结构分析及结构设计技术。它们是在七十年代为了对付应用软件日益增长的复杂程度、漫长的开发周期以及用户对软件产品经常不满意的状况而发展起来的。人类解决复杂问题时普遍采用的一个策略就是“各个击破”，也就是对问题进行分解然后再分别解决各个子问题的策略。软件工程采用的生存周期方法学就是从时间角度对软件开发和维护的复杂问题进行分解，把软件生存的漫长周期依次划分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶段的任务。采用软件工程方法论开发软件的时候，从对任务的抽象逻辑分析开始，一个阶段一个阶段地进行开发。前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的完成通常是使前一阶段提出的解法更进一步具体化，加进了更多的物理细节。每一个阶段的开始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审，从技术和管理两方面对这个阶段的开发成果进行检查，通过之后这个阶段才算结束；如果检查通不过，则必须进行必要的返工，并且返工后还要再经过审查。审查的一条主要标准就是每个阶段都应该交出“最新式的”（即和所开发的软件完全一致的）高质量的文档资料，从而保证在软件开发工程结束时有一个完整准确的软件配置交付使用。文档是通信的工具，它们清楚准确地说明了到这个时候为止，关于该项工程已经知道了什么，同时确立了下一步工作的基础。此外，文档也起备忘录的作用，如果文档不完整，那么一定是某些工作忘记做了，在进入生存周期的下一阶段之前，必须补足这些遗漏的细节。在完成生存周期每个阶段的任务时，应该采用适合该阶段任务特点的系统化的技术方法——结构分析或结构设计技术。
把软件生存周期划分成若干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度；在软件生存周期的每个阶段都采用科学的管理技术和良好的技术方法，而且在每个阶段结束之前都从技术和管理两个角度进行严格的审查，合格之后才开始下一阶段的工作，这就使软件开发工程的全过程以一种有条不紊的方式进行，保证了软件的质量，特别是提高了软件的可维护性。总之，采用软件工程方法论可以大大提高软件开发的成功率，软件开发的生产率也能明显提高。
目前划分软件生存周期阶段的方法有许多种，软件规模、种类、开发方式、开发环境以及开发时使用的方法论都影响软件生存周期阶段的划分。在划分软件生存周期的阶段时应该遵循的一条基本原则就是使各阶段的任务彼此间尽可能相对独立，同一阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂程度，简化不同阶段之间的联系，有利于软件开发工程的组织管理。一般说来，软件生存周期由软件定义、软件开发和软件维护三个时期组成，每个时期又进一步划分成若干个阶段。下面的论述主要针对应用软件，对系统软件也基本适用。
软件定义时期的任务是确定软件开发工程必须完成的总目标；确定工程的可行性，导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并且制定工程进度表。这个时期的工作通常又称为系统分析，由系统分析员负责完成。软件定义时期通常进一步划分成三个阶段，即问题定义、可行性研究和需求分析。
开发时期具体设计和实现在前一个时期定义的软件，它通常由下述四个阶段组成：总体设计，详细设计，编码和单元测试，综合测试。
维护时期的主要任务是使软件持久地满足用户的需要。具体地说，当软件在使用过程中发现错误时应该加以改正；当环境改变时应该修改软件以适应新的环境；当用户有新要求时应该及时改进软件满足用户的新需要。通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。
下面扼要介绍软件生存周期每个阶段的基本任务和结束标准。
1问题定义
问题定义阶段必须回答的关键问题：“要解决的问题是什么？”如果不知道问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费时间和金钱，最终得出的结果很可能是毫无意义的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最容易被忽视的一个步骤。
通过问题定义阶段的工作，系统分析员应该提出关于问题性质、工程目标和规模的书面报告。通过对系统的实际用户和使用部门负责人的访问调查，分析员扼要地写出他对问题的理解，并在用户和使用部门负责人的会议上认真讨论这份书面报告，澄清含糊不精的地方，改正理解不正确的地方，最后得出一份双方都满意的文档。
问题定义阶段是软件生存周期中最简短的阶段，一般只需要一天甚至更少的时间。
2可行性研究
这个阶段要回答的关键问题：“对于上一个阶段所确定的问题有行得通的解决办法吗？”为了回答这个问题，系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程，也就是在较抽象的高层次上进行的分析和设计的过程。
可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。
在问题定义阶段提出的对工程目标和规模的报告通常比较含糊。可行性研究阶段应该导出系统的高层逻辑模型（通常用数据流图表示），并且在此基础上更准确、更具体地确定工程规模和目标。然后分析员更准确地估计系统的成本和效益，对建议的系统进行仔细的成本／效益分析是这个阶段的主要任务之一。
可行性研究的结果是使用部门负责人做出是否继续进行这项工程的决定的重要依据，一般说来，只有投资可能取得较大效益的那些工程项目才值得继续进行下去。可行性研究以后的那些阶段将需要投入要多的人力物力。及时中止不值得投资的工程项目，可以避免更大的浪费。
3需求分析
这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。
用户了解他们所面对的问题，知道必须做什么，但是通常不能完整准确地表达出他们的要求，更不知道怎样利用计算机解决他们的问题；软件开发人员知道怎样使用软件实现人们的要求，但是对特定用户的具体要求并不完全清楚。因此系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。通常用数据流图、数据字典和简要的算法描述表示系统的逻辑模型。
在需求分析阶段确定的系统逻辑模型是以后设计和实现目标系统的基础，因此必须准确完整地体现用户的要求。系统分析员通常都是计算机软件专家，技术专家一般都喜欢很快着手进行具体设计，然而，一旦分析员开始谈论程序设计的细节，就会脱离用户，使他们不能继续提出他们的要求和建议。较件工程使用的结构分析设计的方法为每个阶段都规定了特定的结束标准，需求分析阶段必须提供完整准确的系统逻辑模型，经过用户确认之后才能进入下一个阶段，这就可以有效地防止和克服急于着手进行具体设计的倾向。
4总体设计
这个阶段必须回答的关键问题是：“概括地说，应该如何解决这个问题？”
首先，应该考虑几种可能的解决方案。列如，目标系统的一些主要功能是用计算机自动完成还是用人工完成；如果使用计算机，那么是使用批处理方式还是人机交互方式；信息存储使用传统的文件系统还是数据库……。通常至少应该考虑下述几类可能的方案：
低成本的解决方案。系统只能完成最必要的工作，不能多做一点额处的工作。
中等成本的解决方案。这样的系统不仅能够很好地完成预定的任务，使用起来很方便，而且可能还具有用户没有具体指定的某些功能和特点。虽然用户没有提出这些具体要求，但是系统分析员根据自己的知识和经验断定，这些附加的能力在实践中将证明是很有价值的。
高成本的“十全十美”的系统。这样的系统具有用户可能希望有的所有功能和特点。
系统分析员应该使用系统流程图或其他工具描述每种可能的系统，估计每种方案的成本和效益，还应该在充分权衡各种方案的利弊的基础上,推荐一个较好的系统 (最佳方案),并且制定实现所推荐的系统的详细计划。如果用户接受分析员推荐的系统，则可以着手完成本阶段的另一项主要工作。
上面的工作确定了解决问题的策略以及目标系统需要哪些程序，但是，怎样设计这些程序呢？结构设计的一条基本原理就是程序应该模块化，也就是一个大程序应该由许多规模适中的模块按合理的层次结构组织而成。总体设计阶段的第二项主要任务就是设计软件的结构，也就是确定程序由哪些模块组成以及模块间的关系。通常用层次图或结构图描绘软件的结构。
5详细设计
总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解法具体化，也就是回答下面这个关键问题：“应该怎样具体地实现这个系统呢？”
这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该包含必要的细节，程序员可以根据它们写出实际的程序代码。
通常用HIPO图（层次图加输入／处理／输出图）或PDL语言（过程设计语言）描述详细设计的结果。
6编码和单元测试
这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块。
程序员应该根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言（必要时用汇编语言），把说细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。
7综合测试
这个阶段的关键任务是通过各种类型的测试（及相应的调试）使软件达到预定的要求。
最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。所谓验收测试则是按照规格说明书的规定（通常在需求分析阶段确定），由用户（或在用户积极参加下）对目标系统进行验收。
必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验。
为了使用户能够积极参加验收测试，并且在系统投入生产性运行以后能够正确有效地使用这个系统，通常需要以正式的或非正式的方式对用户进行培训。
通过对软件测试结果的分析可以预测软件的可靠性；反之，根据对软件可靠性的要求也可以决定测试和调试过程什么时候可以结束。
应该用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来，做为软件配置的一个组成成分。
8软件维护
维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。
通常有四类维护活动：改正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化；完善性维护，即根据用户的要求改进或扩充软件使它更完善；预防性维护，即修改软件为将来的维护活动预先做准备。
虽然没有把维护阶段进一步划分成更小的阶段，但是实际上每一项维护活动都应该经过提出维护要求（或报告问题），分析维护要求，提出维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修改程序，测试程序，复查验收等一系列步骤，因此实质上是经历了一次压缩和简化了的软件定义和开发的全过程。
都应该经过提出维护要求（或报告问题），分析维护要求，提出维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修改程序，测试程序，复查验收等一系列步骤，因此实质上是经历了一次压缩和简化了的软件定义和开发的全过程。

② 极限编程的核心价值

极限编程中有四个核心价值是我们在开发中必须注意的：沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）、此外还扩展了第五个价值观：谦逊（Modesty）。 XP用“沟通、简单、反馈、勇气和谦逊”来减轻开发压力和包袱；无论是术语命名、专着叙述内容和方式、过程要求，都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。
XP精神可以启发我们如何学习和对待快速变化、多样的开发技术。成功学习XP的关键，是用“沟通、简单、反馈、勇气和谦逊”的态度来对待XP；轻松愉快地来感受XP的实践思想；自己认真实践后，通过对真实反馈的分析，来决定XP对自己的价值；有勇气接受它，或改进它。

③ 软件测试

软件测试知识点
一.软件测试基本概念
1.软件质量的概念
功能性：软件提供明确与隐含功能的能力
可靠性：维持规定性能的能力
易用性：被理解学习使用和吸引用户的能力
效率：相对于所用资源的数量，软件产品可提供适应性能的能力
可维护性：纠正错误，改进功能，适应环境的能力
可移植性：迁移到另一种环境的能力
2.软件测试目标和原则
目标：以最少的时间和人力，系统地找出软件潜在的各种错误和缺陷
原则：1.尽早和不断地进行软件测试；
2.测试用例应该由测试输入数据和预期输出结果构成；
3.程序员尽量避免测试自己的程序（最好是独立于开发组和客户的第三方测试组和机构）
4.测试应包括合理的和不合理的输出条件，
5。注意测试中的集群现象（测试后的程序残存的错误数目与已经发现的成正比）
6.严格执行测试计划，排除随意性7.对每一个结果做全面检查
8.妥善保管测试计划用例出错统计和分析报告
3.软件测试心理学
1)程序测试过程具有破坏性:测试是为了发现错误而执行程序的过程
2)程序员尽量避免测试自己的程序
3)程序设计组织不应测试自己的程序
4.软件测试的经济学:不能发现”所有”的缺陷和错误
1.黑盒测试(数据驱动测试/输入输出驱动测试):测试人员完全不考虑程序内部的特性,和逻辑结构,只根据程序的需求规格说明书,检查程序是否符合他的功能说明
2.白盒测试(逻辑驱动测试):对程序的逻辑结构进行检查
5.软件质量保证’

二.软件测试类型以其地位
1.软件开发阶段:
1.生存周期:制定规划(功能需求可靠性接口可行性资源，可行性报告)——系统与软件需求定义——软件设计(技术核心)——编程和单元测试——系统与集成测试——运行和维护
2.测试信息流:软件配置,测试配置,测试工具
2.规划阶段的测试:目标阐述(不太详细也不具体),需求分析,功能定义,规划阶段的测试
3.设计阶段的测试:外部设计(用户界面),内部设计(结构设计,数据设计,逻辑设计),伪代码分析
4.编程阶段的测试:白盒测试与黑盒测试，结构测试与功能测试，路径测试:覆盖准则，增量测试与大突击测试
三．代码检查、走查和评审
1.桌面检查：程序员检查自己编写的程序，是在进行单元测试之前对代码进行分析
2.代码检查：以小组为单位阅读代码，
1.协调人：主持、引导代码检查的过程
2.开发人员：检查项目的生产者
3.检查人员：检查小组每一个人都可以认为是一个检查人员，可以兼任不同的角色。
4.解说员5.记录员
项目：变量是否喂赋值或者初始化？上下标是否在界限之内？是不是整数？是否分配了数值的内存单元？变量的数据类型是否与编译器所预期的一致？
3.走查：与代码检查类似，以小组为单位进行，进行一些列规程的错误检查技术的集合
4．同行评审：通过作者的同行来确认缺陷和需要变更区域检查的方法
评审的方法和技术：
1. 临时评审：一位程序员临时请另一位花几分钟时间查找一个缺陷
2. 桌上检查或轮查：多人进行的并行桌上检查
3. 结对评审：作者请另一位同行进行桌上检查
4. 走查：5.小组评审。6.正式审查
四．覆盖率测试
1.概念：度量测试完整性的手段
覆盖率=被执行的项目数/项总数 ×100%
2.逻辑结构的覆盖测试
◇判定，□语句，○程序的开始或者结束，
1.语句覆盖率=被评价用到的语句数/可执行的语句总数 ×100%
2.指令块：不存在（会引起分支）的控制语句，IB
IB覆盖率=被执行的语句块数量/程序中的指令块总数 ×100%
3.判定覆盖率=被执行的分支数量/程序中的分支总数 ×100%
DDP覆盖率=被评价到的判定路径数量/程序中的判定路径总数 ×100%
5. 条件覆盖=被评价到的条件取值数量/条件取值总数 ×100%
3.路径测试覆盖：
1.分支结构的路径测试：①对于嵌套型分支结构，若有n个判定语句，则存在n+1条不同的路径
②对于串联型分支结构，若有n个判定语句，则有2n个路径 →减少测试用例，构造正交表P71
2.循环结构的路径测试：简单循环，嵌套循环，连锁循环，非结构循环
4.数据流测试：关注在一条路径上变量在何处赋值，在何处引用
佣金问题伪代码描述：P79
5.基于覆盖测试的数据选择
如何使用覆盖率①覆盖率不是目的，只是一种手段②不能针对所有的覆盖率指标进行测试③不能追求100%的覆盖率
五．黑盒测试
1.等价类测试：降数目极多的数据化成等价类，然后测试某类的代表值
原则：①如果确定了取值范围或者取值的个数，则可以确立一个有效等价类和两个无效等价类
②如果输入条件规定了输入值的集合，则可以有一个有效和一个无效等价类
2.边界值测试：用例：刚达到这个范围的值，比最大范围多1或者少1，如果输入输出域是有序集合，则采用边界
3.基于因果图的测试：E互斥，I包含（至少一个成立）O唯一 R要求（a→b）M屏蔽（a1则b0）
4.基于状态图的测试：P105
六．单元测试和集成测试
1.单元测试的目标和模型：
1.单元：可以编译和执行的最小软件构件、不会指派给多个设计人员开发
2.目标：验证代码是与设计相合的，跟踪需求和设计的实现和缺陷，发现编码过程中引入的错误
3.模型：（与集成，系统测试区别：P120）

2.单元测试的策略
1.自顶向下：逐层打桩 2.自底向上：自下向上打桩 3.孤立测试：为每个模块单独打桩
4.综合测试
3.单元测试分析：
1.模块接口
2.局部数据结构：保证临时存储在模块内的数据的完整正确
3.独立路径：保证每个模块的每条语句至少执行一次
4.出错处理：预见各种出错条件，进行适当的处理
5.边界条件.
4.集成测试的基本概念
1.定义：对系统接口和集成后的功能的正确性进行检验
2.与系统测试区别：
①测试对象 集成：各个模块的构件 系统：软硬件以及相关的外围设备，数据采集传输等
②测试时间 集成介于单元和系统测试之间
③ 测试方法：单元白盒，集成灰盒，系统黑盒
5.集成测试策略：
1.基于分解
①一次性集成测试②自顶向下增量式测试③自底向上的增量式集成测试④三明治集成
2.基于功能的集成：采用增量式集成测试方法
3.基于调用图的集成：成对测试，相邻测试
4.基于路径的集成 5.基于进度的集成
6集成测试分析
1.体系结构分析：
①根据需求分析，划分结构层次图
②对各个结构之间的依赖关系进行分析，确定测试模块的大小
2.模块分析 3.接口分析 4.可测试性分析
七．系统测试
1.概念：软件开发完成后，还要与系统的其他部分结合起来才能运行，系统测试的目的就是对各部分进行集成和确认测试
2.系统测试的方法：
①功能测试：是否有不正确或者遗漏的功能，能否满足系统和用户的隐式需求，能否正确接受输入
②协调一致测试
③性能测试：度量系统的性能与预先定义的目标有多大差距：压力测试：
④压力测试：测试者想要破坏程序，边界测试
⑤容量测试⑥安全性测试⑦失效恢复测试⑧备份测试GUI图形化用户接口测试⑩健壮性测试
易用性测试、安装测试、文档测试、在线帮助测试
3.系统测试的实施
①确认测试：有效性测试
②α测试和β测试：内部用户/内测
③验收测试：
④回归测试：软件变更后对其进行重新测试
八．软件性能测试和可靠性测试
1.软件性能的概念：完成某项功能时展现出来的及时性
指标：响应时间（平均，最大），吞吐量，并发用户数，资源利用率
2.性能测试的执行：
3.软件可靠性的概念：在规定时间条件内，软件不引起失效的概率
软硬件可靠性区别：
① 唯一性：软件每份拷贝都相同，硬件不能相同
② 物理退化：硬件可靠性下降
③ 逻辑复杂性：软件是纯逻辑产品，其失效也主要是逻辑错误
④ 版本更新：硬件较慢，软件较快
4.软件可靠性预计：
①软件的运行剖面与可靠性剖面一致②一旦发生故障，立即修复，不引入新的故障③故障和失效是相互独立的④每个故障发生的概率相等
九．面向对象的软件测试
1. 面向对象的软件测试的问题
1.封装：信息隐蔽，一组相关变量和方法被封装在同一个类中
2.继承：子类直接获得父类的属性和方法 充分性，误用
3.多态
2. 面向对象的软件测试模型：分析测试（OOA），设计测试（OOD）编程测试（OOP）
3. 面向对象的软件测试策略：检查分析结果是否附和相应的面向对象分析方法要求，分析检查结果是否满足软件需求
十：WEB应用测试
1. 应用服务器的分类：
① 面向的领域：通用应用服务器（提供多方面服务），专用应用服务器
② 循环的规范：
2. WEB应用的测试策略
1. 表示层的测试：拍板结构，链接结构，客户端程序，浏览器兼容性
2. 业务层的测试：单个程序（尽可能白盒测试），对一组程序
3. 数据层的测试：
3.WEB软件的测试技术：
1.功能测试：链接测试，表单测试，Cookies测试
2.性能测试：并发测试，负载测试和性能调优
3.安全性测试：服务器，客户端，Cookies，日志功能
4.接口测试：使用接口，提供接口
4.系统安全检测与防护
1.入侵检测 狭义：黑客进入一个系统 广义：窃取数据，滥用服务器，发送垃圾邮件
2.漏洞扫描 操作系统漏洞，网络漏洞，数据库漏洞
3.安全策略 ①物理破坏防护：远离火灾，人为破坏
②信息窃取防护：入网访问控制,权限控制（用户权限，操作权限），服务器和节点安全控制，网络监测控制，防火墙控制
③信息加密：保护策略，加密算法
十一.其他测试
1. 兼容性测试①不同的硬件配置影响软件性能②软件使用了硬件的特定功能
1. 软件兼容性测试：与操作系统，数据库，浏览器，中间件，其他软件 兼容性
2. 数据兼容性：不同版本数据，不同软件间兼容性
2.易用性测试
1.易安装性测试：安装手册自动化程度，灵活性，中断处理，安装和卸载，多环境安装支持
2.功能易用性测试：业务符合度，功能定制性，功能关联度，数据共享度，用户约束的合理性
3.用户界面测试：界面整体(合理一致规范)，界面元素，输入测试
3.构件测试：
4.极限测试：
1.极限编程：①特性：简单的分析设计，频繁的客户交流，增量式开发，连续的测试
②优点：随时应对新增或改变的需求
2.极限测试①单元测试：最重要的发现错误的手段，由编码人员完成，在编程之前测试
②极限测试的实施：单元测试用例的生成
5.文档测试：只能以文档审查的方式进行
内容：宣传和包装材料，用户许可说明书，手册，在线帮助，示例和模板
文档的测试

④ 极限编程和其它的软件开发方法的区别。 尽量全一点。2000字左右

极限编程（ExtremeProgramming，简称XP）是由KentBeck在1996年提出的。KentBeck在九十年代初期与WardCunningham共事时，就一直共同探索着新的软件开发方法，希望能使软件开发更加简单而有效。Kent仔细地观察和分析了各种简化软件开发的前提条件、可能行以及面临的困难。1996年三月，Kent终于在为DaimlerChrysler所做的一个项目中引入了新的软件开发观念——XP。

极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

极限编程中有四个核心价值是我们在开发中必须注意的：沟通（Communication）、简单（Simplicity）、反馈（Feedback）和勇气（Courage）。 XP用“沟通、简单、反馈和勇气”来减轻开发压力和包袱；无论是术语命名、专着叙述内容和方式、过程要求，都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。

XP精神可以启发我们如何学习和对待快速变化、多样的开发技术。成功学习XP的关键，是用“沟通、简单、反馈和勇气”的态度来对待XP；轻松愉快地来感受XP的实践思想；自己认真实践后，通过对真实反馈的分析，来决定XP对自己的价值；有勇气接受它，或改进它。

XP中一些基本概念的简介 UserStory：开发人员要求客户把所有的需求写成一个个独立的小故事，每个只需要几天时间就可以完成。开发过程中，客户可以随时提出新的UserStory，或者更改以前的UserStory。 StoryEstimates和开发速度：开发小组对每个UserStory进行估算，并根据每个开发周期（Iteration）中的实际情况反复计算开发速度。这样，开发人员和客户能知道每个星期到底能开发多少UserStory。 ReleasePlan和ReleaseScope：整个开发过程中，开发人员将不断地发布新版本。开发人员和客户一起确定每个发布所包含的UserStory。 Iteration（开发周期，或称迭代）和IterationPlan：在一个Release过程中，开发人员要求客户选择最有价值的UserStory作为未来一两个星期的开发内容。 TheSeed：第一个迭代（Iteration）完成后，提交给客户的系统。虽然这不是最终的产品，但它已经实现了几个客户认为是最重要的Story，开发人员将逐步在其基础上增加新的模块。 ContinuousIntegration（整合）：把开发完的UserStory的模块一个个拼装起来，一步步接近乃至最终完成最终产品。 验收测试（功能测试）：对于每个UserStory，客户将定义一些测试案例，开发人员将使运行这些测试案例的过程自动化。 UnitTest（单元测试）：在开始写程序前，程序员针对大部分类的方法，先写出相应的测试程序。 Refactoring(重构)：去掉代码中的冗余部分，增加代码的可重用性和伸缩性。

⑤ 极限编程的方法

基于敏捷的核心思想和价值目标，XP要求项目团队遵循13个核心实践
团队协作(Whole Team)
规划策略(The Planning Game)；
结对编程(Pair programming)
测试驱动开发(Testing-Driven Development)
重构(Refactoring)
简单设计(Simple Design)
代码集体所有权(Collective Code Ownership)
持续集成(Continuous Integration)
客户测试(Customer Tests)
小型发布（Small Release）
每周40小时工作制（40-hour Week）
编码规范（Code Standards）
系统隐喻（System Metaphor） 计划项目（PlanningGame）、验收测试、小规模发布（SmallReleases）
XP开发小组使用简单的方式进行项目计划和开发跟踪，并以此预测项目进展情况和决定未来的步骤。根据需求的商业价值，开发小组针对一组组的需求进行一系列的开发和整合，每次开发都会产生一个通过测试的、可以使用的系统。

⑥ 极限编程xp与scrum的区别有哪些

m的迭代长度一般为 2~ 4周. 区别之二: 在迭代中, 是否允许修改需求 XP 在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现， 则可以考虑用另外的需

⑦ 代码重构的概述

重构（），通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。也许有人会问，为什么不在项目开始时多花些时间把设计做好，而要以后花时间来重构呢？要知道一个完美得可以预见未来任何变化的设计，或一个灵活得可以容纳任何扩展的设计是不存在的。系统设计人员对即将着手的项目往往只能从大方向予以把控，而无法知道每个细枝末节，其次永远不变的就是变化，提出需求的用户往往要在软件成型后，才开始品头论足，系统设计人员毕竟不是先知先觉的神仙，功能的变化导致设计的调整再所难免。所以测试为先，持续重构作为良好开发习惯被越来越多的人所采纳，测试和重构像黄河的护堤，成为保证软件质量的法宝。 在不改变系统功能的情况下，改变系统的实现方式。为什么要这么做？投入精力不用来满足客户关心的需求，而是仅仅改变了软件的实现方式，这是否是在浪费客户的投资呢？
重构的重要性要从软件的生命周期说起。软件不同与普通的产品，他是一种智力产品，没有具体的物理形态。一个软件不可能发生物理损耗，界面上的按钮永远不会因为按动次数太多而发生接触不良。那么为什么一个软件制造出来以后，却不能永远使用下去呢？
对软件的生命造成威胁的因素只有一个：需求的变更。一个软件总是为解决某种特定的需求而产生，时代在发展，客户的业务也在发生变化。有的需求相对稳定一些，有的需求变化的比较剧烈，还有的需求已经消失了，或者转化成了别的需求。在这种情况下，软件必须相应的改变。
考虑到成本和时间等因素，当然不是所有的需求变化都要在软件系统中实现。但是总的说来，软件要适应需求的变化，以保持自己的生命力。
这就产生了一种糟糕的现象：软件产品最初制造出来，是经过精心的设计，具有良好架构的。但是随着时间的发展、需求的变化，必须不断的修改原有的功能、追加新的功能，还免不了有一些缺陷需要修改。为了实现变更，不可避免的要违反最初的设计构架。经过一段时间以后，软件的架构就千疮百孔了。bug越来越多，越来越难维护，新的需求越来越难实现，软件的构架对新的需求渐渐的失去支持能力，而是成为一种制约。最后新需求的开发成本会超过开发一个新的软件的成本，这就是这个软件系统的生命走到尽头的时候。
重构就能够最大限度的避免这样一种现象。系统发展到一定阶段后，使用重构的方式，不改变系统的外部功能，只对内部的结构进行重新的整理。通过重构，不断的调整系统的结构，使系统对于需求的变更始终具有较强的适应能力。
通过重构可以达到以下的目标：
·持续纠偏和改进软件设计
重构和设计是相辅相成的，它和设计彼此互补。有了重构，你仍然必须做预先的设计，但是不必是最优的设计，只需要一个合理的解决方案就够了，如果没有重构、程序设计会逐渐腐败变质，愈来愈像断线的风筝，脱缰的野马无法控制。重构其实就是整理代码，让所有带着发散倾向的代码回归本位。
·
Martin Flower在《重构》中有一句经典的话：任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类容易理解的程序才是优秀的程序员。对此，笔者感触很深，有些程序员总是能够快速编写出可运行的代码，但代码中晦涩的命名使人晕眩得需要紧握坐椅扶手，试想一个新兵到来接手这样的代码他会不会想当逃兵呢？
软件的生命周期往往需要多批程序员来维护，我们往往忽略了这些后来人。为了使代码容易被他人理解，需要在实现软件功能时做许多额外的事件，如清晰的排版布局，简明扼要的注释，其中命名也是一个重要的方面。一个很好的办法就是采用暗喻命名，即以对象实现的功能的依据，用形象化或拟人化的手法进行命名，一个很好的态度就是将每个代码元素像新生儿一样命名，也许笔者有点命名偏执狂的倾向，如能荣此雅号，将深以此为幸。
对于那些让人充满迷茫感甚至误导性的命名，需要果决地、大刀阔斧地整容，永远不要手下留情！
·帮助发现隐藏的代码缺陷
孔子说过：温故而知新。重构代码时逼迫你加深理解原先所写的代码。笔者常有写下程序后，却发生对自己的程序逻辑不甚理解的情景，曾为此惊悚过，后来发现这种症状居然是许多程序员常患的感冒。当你也发生这样的情形时，通过重构代码可以加深对原设计的理解，发现其中的问题和隐患，构建出更好的代码。
·从长远来看，有助于提高编程效率
当你发现解决一个问题变得异常复杂时，往往不是问题本身造成的，而是你用错了方法，拙劣的设计往往导致臃肿的编码。
改善设计、提高可读性、减少缺陷都是为了稳住阵脚。良好的设计是成功的一半，停下来通过重构改进设计，或许会在当前减缓速度，但它带来的后发优势却是不可低估的。 新官上任三把火，开始一个全新??、脚不停蹄、加班加点，一支声势浩大的千军万码夹裹着程序员激情和扣击键盘的鸣金奋力前行，势如破竹，攻城掠地，直指黄龙府。
开发经理是这支浩浩汤汤代码队伍的统帅，他负责这支队伍的命运，当齐桓公站在山顶上看到管仲训练的队伍整齐划一地前进时，他感叹说我有这样一支军队哪里还怕没有胜利呢？。但很遗憾，你手中的这支队伍原本只是散兵游勇，在前进中招兵买马，不断壮大，所以队伍变形在所难免。当开发经理发觉队伍变形时，也许就是克制住攻克前方山头的诱惑，停下脚步整顿队伍的时候了。
Kent Beck提出了代码坏味道的说法，和我们所提出的队伍变形是同样的意思，队伍变形的信号是什么呢？以下列述的代码症状就是队伍变形的强烈信号：
·代码中存在重复的代码
中国有118 家整车生产企业，数量几乎等于美、日、欧所有汽车厂家数之和，但是全国的年产量却不及一个外国大汽车公司的产量。重复建设只会导致效率的低效和资源的浪费。
程序代码更是不能搞重复建设，如果同一个类中有相同的代码块，请把它提炼成类的一个独立方法，如果不同类中具有相同的代码，请把它提炼成一个新类，永远不要重复代码。
·过大的类和过长的方法
过大的类往往是类抽象不合理的结果，类抽象不合理将降低了代码的复用率。方法是类王国中的诸侯国，诸侯国太大势必动摇中央集权。过长的方法由于包含的逻辑过于复杂，错误机率将直线上升，而可读性则直线下降，类的健壮性很容易被打破。当看到一个过长的方法时，需要想办法将其划分为多个小方法，以便于分而治之。
·牵一毛而需要动全身的修改
当你发现修改一个小功能，或增加一个小功能时，就引发一次代码地震，也许是你的设计抽象度不够理想，功能代码太过分散所引起的。
·类之间需要过多的通讯
A类需要调用B类的过多方法访问B的内部数据，在关系上这两个类显得有点狎昵，可能这两个类本应该在一起，而不应该分家。
·过度耦合的信息链
计算机是这样一门科学，它相信可以通过添加一个中间层解决任何问题，所以往往中间层会被过多地追加到程序中。如果你在代码中看到需要获取一个信息，需要一个类的方法调用另一个类的方法，层层挂接，就象输油管一样节节相连。这往往是因为衔接层太多造成的，需要查看就否有可移除的中间层，或是否可以提供更直接的调用方法。
·各立山头干革命
如果你发现有两个类或两个方法虽然命名不同但却拥有相似或相同的功能，你会发现往往是因为开发团队协调不够造成的。笔者曾经写了一个颇好用的字符串处理类，但因为没有及时通告团队其他人员，后来发现项目中居然有三个字符串处理类。革命资源是珍贵的，我们不应各立山头干革命。
·不完美的设计
在笔者刚完成的一个比对报警项目中，曾安排阿朱开发报警模块，即通过Socket向指定的短信平台、语音平台及客户端报警器插件发送报警报文信息，阿朱出色地完成了这项任务。后来用户又提出了实时比对的需求，即要求第三方系统以报文形式向比对报警系统发送请求，比对报警系统接收并响应这个请求。这又需要用到Socket报文通讯，由于原来的设计没有将报文通讯模块独立出来，所以无法复用阿朱开发的代码。后来我及时调整了这个设计，新增了一个报文收发模块，使系统所有的对外通讯都复用这个模块，系统的整体设计也显得更加合理。
每个系统都或多或少存在不完美的设计，刚开始可能注意不到，到后来才会慢慢凸显出来，此时唯有勇于更改才是最好的出路。
·缺少必要的注释
虽然许多软件工程的书籍常提醒程序员需要防止过多注释，但这个担心好象并没有什么必要。往往程序员更感兴趣的是功能实现而非代码注释，因为前者更能带来成就感，所以代码注释往往不是过多而是过少，过于简单。人的记忆曲线下降的坡度是陡得吓人的，当过了一段时间后再回头补注释时，很容易发生提笔忘字，愈言且止的情形。
曾在网上看到过微软的代码注释，其详尽程度让人叹为观止，也从中体悟到了微软成功的一个经验。 学习一种可以大幅提高生产力的新技术时，你总是难以察觉其不适用的场合。通常你在一个特定场景中学习它，这个场景往往是个项目。这种情况下你很难看出什么会造成这种新技术成效不彰或甚至形成危害。十年前，对象技术（object tech.）的情况也是如此。那时如果有人问我“何时不要使用对象”，我很难回答。并非我认为对象十全十美、没有局限性 — 我最反对这种盲目态度，而是尽管我知道它的好处，但确实不知道其局限性在哪儿。
现在，重构的处境也是如此。我们知道重构的好处，我们知道重构可以给我们的工作带来垂手可得的改变。但是我们还没有获得足够的经验，我们还看不到它的局限性。
这一小节比我希望的要短。暂且如此吧。随着更多人学会重构技巧，我们也将对??你应该尝试一下重构，获得它所提供的利益，但在此同时，你也应该时时监控其过程，注意寻找重构可能引入的问题。请让我们知道你所遭遇的问题。随着对重构的了解日益增多，我们将找出更多解决办法，并清楚知道哪些问题是真正难以解决的。
·数据库（Databases）
“重构”经常出问题的一个领域就是数据库。绝大多数商用程序都与它们背后的database schema（数据库表格结构）紧密耦合（coupled）在一起，这也是database schema如此难以修改的原因之一。另一个原因是数据迁移（migration）。就算你非常小心地将系统分层（layered），将database schema和对象模型（object model）间的依赖降至最低，但database schema的改变还是让你不得不迁移所有数据，这可能是件漫长而烦琐的工作。
在“非对象数据库”（nonobject databases）中，解决这个问题的办法之一就是：在对象模型（object model）和数据库模型（database model）之间插入一个分隔层（separate layer），这就可以隔离两个模型各自的变化。升级某一模型时无需同时升级另一模型，只需升级上述的分隔层即可。这样的分隔层会增加系统复杂度，但可以给你很大的灵活度。如果你同时拥有多个数据库，或如果数据库模型较为复杂使你难以控制，那么即使不进行重构，这分隔层也是很重要的。
你无需一开始就插入分隔层，可以在发现对象模型变得不稳定时再产生它。这样你就可以为你的改变找到最好的杠杆效应。
对开发者而言，对象数据库既有帮助也有妨碍。某些面向对象数据库提供不同版本的对象之间的自动迁移功能，这减少了数据迁移时的工作量，但还是会损失一定时间。如果各数据库之间的数据迁移并非自动进行，你就必须自行完成迁移工作，这个工作量可是很大的。这种情况下你必须更加留神classes内的数据结构变化。你仍然可以放心将classes的行为转移过去，但转移值域（field）时就必须格外小心。数据尚未被转移前你就得先运用访问函数（accessors）造成“数据已经转移”的假象。一旦你确定知道“数据应该在何处”时，就可以一次性地将数据迁移过去。这时惟一需要修改的只有访问函数（accessors），这也降低了错误风险。
·修改接口（Changing Interfaces）
关于对象，另一件重要事情是：它们允许你分开修改软件模块的实现（implementation）和接口（interface）。你可以安全地修改某对象内部而不影响他人，但对于接口要特别谨慎 — 如果接口被修改了，任何事情都有可能发生。
一直对重构带来困扰的一件事就是：许多重构手法的确会修改接口。像Rename Method（273）这么简单的重构手法所做的一切就是修改接口。这对极为珍贵的封装概念会带来什么影响呢？
如果某个函数的所有调用动作都在你的控制之下，那么即使修改函数名称也不会有任何问题。哪怕面对一个public函数，只要能取得并修改其所有调用者，你也可以安心地将这个函数易名。只有当需要修改的接口系被那些“找不到，即使找到也不能修改”的代码使用时，接口的修改才会成为问题。如果情况真是如此，我就会说：这个接口是个“已发布接口”（published interface）— 比公开接口（public interface）更进一步。接口一旦发行，你就再也无法仅仅修改调用者而能够安全地修改接口了。你需要一个略为复杂的程序。
这个想法改变了我们的问题。如今的问题是：该如何面对那些必须修改“已发布接口”的重构手法？
简言之，如果重构手法改变了已发布接口（published interface），你必须同时维护新旧两个接口，直到你的所有用户都有时间对这个变化做出反应。幸运的是这不太困难。你通常都有办法把事情组织好，让旧接口继续工作。请尽量这么做：让旧接口调用新接口。当你要修改某个函数名称时，请留下旧函数，让它调用新函数。千万不要拷贝函数实现码，那会让你陷入“重复代码”（plicated code）的泥淖中难以自拔。你还应该使用java提供的 deprecation（反对）设施，将旧接口标记为 deprecated。这么一来你的调用者就会注意到它了。
这个过程的一个好例子就是Java容器类（collection classes）。Java 2的新容器取代了原先一些容器。当Java 2容器发布时，JavaSoft花了很大力气来为开发者提供一条顺利迁徙之路。
“保留旧接口”的办法通常可行，但很烦人。起码在一段时间里你必须建造（build）并维护一些额外的函数。它们会使接口变得复杂，使接口难以使用。还好我们有另一个选择：不要发布（publish）接口。当然我不是说要完全禁止，因为很明显你必得发布一些接口。如果你正在建造供外部使用的APIs，像Sun所做的那样，肯定你必得发布接口。我之所以说尽量不要发布，是因为我常常看到一些开发团队公开了太多接口。我曾经看到一支三人团队这么工作：每个人都向另外两人公开发布接口。这使他们不得不经常来回维护接口，而其实他们原本可以直接进入程序库，径行修改自己管理的那一部分，那会轻松许多。过度强调“代码拥有权”的团队常常会犯这种错误。发布接口很有用，但也有代价。所以除非真有必要，别发布接口。这可能意味需要改变你的代码拥有权观念，让每个人都可以修改别人的代码，以运应接口的改动。以搭档（成对）编程（Pair Programming）完成这一切通常是个好主意。
不要过早发布（published）接口。请修改你的代码拥有权政策，使重构更顺畅。
Java之中还有一个特别关于“修改接口”的问题：在throws子句中增加一个异常。这并不是对签名式（signature）的修改，所以你无法以delegation（委托手法）隐藏它。但如果用户代码不作出相应修改，编译器不会让它通过。这个问题很难解决。你可以为这个函数选择一个新名tion（可控式异常）转换成一个unchecked exception（不可控异常）。你也可以抛出一个unchecked异常，不过这样你就会失去检验能力。如果你那么做，你可以警告调用者：这个unchecked异常日后会变成一个checked异常。这样他们就有时间在自己的代码中加上对此异常的处理。出于这个原因，我总是喜欢为整个package定义一个superclass异常（就像java.sql的SQLException），并确保所有public函数只在自己的throws子句中声明这个异常。这样我就可以随心所欲地定义subclass异常，不会影响调用者，因为调用者永远只知道那个更具一般性的superclass异常。
·难以通过重构手法完成的设计改动
通过重构，可以排除所有设计错误吗？是否存在某些核心设计决策，无法以重构手法修改？在这个领域里，我们的统计数据尚不完整。当然某些情况下我们可以很有效地重构，这常常令我们倍感惊讶，但的确也有难以重构的地方。比如说在一个项目中，我们很难（但还是有可能）将“无安全需求（no security requirements）情况下构造起来的系统”重构为“安全性良好的（good security）系统”。
这种情况下我的办法就是“先想象重构的情况”。考虑候选设计方案时，我会问自己：将某个设计重构为另一个设计的难度有多大？如果看上去很简单，我就不必太担心选择是否得当，于是我就会选最简单的设计，哪怕它不能覆盖所有潜在需求也没关系。但如果预先看不到简单的重构办法，我就会在设计上投入更多力气。不过我发现，这种情况很少出现。
·何时不该重构？
有时候你根本不应该重构 — 例如当你应该重新编写所有代码的时候。有时候既有代码实在太混乱，重构它还不如从新写一个来得简单。作出这种决定很困难，我承认我也没有什么好准则可以判断何时应该放弃重构。
重写（而非重构）的一个清楚讯号就是：现有代码根本不能正常运作。你可能只是试着做点测试，然后就发现代码中满是错误，根本无法稳定运作。记住，重构之前，代码必须起码能够在大部分情况下正常运作。
一个折衷办法就是：将“大块头软件”重构为“封装良好的小型组件”。然后你就可以逐一对组件作出“重构或重建”的决定。这是一个颇具希望的办法，但我还没有足够数据，所以也无法写出优秀的指导原则。对于一个重要的古老系统，这肯定会是一个很好的方向。
另外，如果项目已近最后期限，你也应该避免重构。在此时机，从重构过程赢得的生产力只有在最后期限过后才能体现出来，而那个时候已经时不我予。Ward Cunningham对此有一个很好的看法。他把未完成的重构工作形容为“债务”。很多公司都需要借债来使自己更有效地运转。但是借债就得付利息，过于复杂的代码所造成的“维护和扩展的额外开销”就是利息。你可以承受一定程度的利息，但如果利息太高你就会被压垮。把债务管理好是很重要的，你应该随时通过重构来偿还一部分债务。
如果项目已经非常接近最后期限，你不应该再分心于重构，因为已经没有时间了。不过多个项目经验显示：重构的确能够提高生产力。如果最后你没有足够时间，通常就表示你其实早该进行重构。 “重构”肩负一项特别任务：它和设计彼此互补。初学编程的时候，我埋头就写程序，浑浑噩噩地进行开发。然而很快我便发现，“事先设计”（upfront design）可以助我节省回头工的高昂成本。于是我很快加强这种“预先设计”风格。许多人都把设计看作软件开发的关键环节，而把编程（programming）看作只是机械式的低级劳动。他们认为设计就像画工程图而编码就像施工。但是你要知道，软件和真实器械有着很大的差异。软件的可塑性更强，而且完全是思想产品。正如Alistair Cockburn所说：‘有了设计，我可以思考更快，但是其中充满小漏洞。’
有一种观点认为：重构可以成为“预先设计”的替代品。这意思是你根本不必做任何设计，只管按照最初想法开始编码，让代码有效运作，然后再将它重构成型。事实上这种办法真的可行。我的确看过有人这么做，最后获得设计良好的软件。极限编程（Extreme Programming）【Beck, XP】 的支持者极力提倡这种办法。
尽管如上所言，只运用重构也能收到效果，但这并不是最有效的途径。是的，即使极限编程（Extreme Programming）爱好者也会进行预先设计。他们会使用CRC卡或类似的东西来检验各种不同想法，然后才得到第一个可被接受的解决方案，然后才能开始编码，然后才能重构。关键在于：重构改变了“预先设计”的角色。如果没有重构，你就必须保证“预先设计”正确无误，这个压力太大了。这意味如果将来需要对原始设计做任何修改，代价都将非常高昂。因此你需要把更多时间和精力放在预先设计上，以避免日后修改。
如果你选择重构，问题的重点就转变了。你仍然做预先设计，但是不必一定找出正确的解决方案。此刻的你只需要得到一个足够合理的解决方案就够了。你很肯定地知道，在实现这个初始解决方案的时候，你对问题的理解也会逐渐加深，你可能会察觉最佳解决方案和你当初设想的有些不同。只要有重构这项武器在手，就不成问题，因为重构让日后的修改成本不再高昂。
这种转变导致一个重要结果：软件设计朝向简化前进了一大步。过去未曾运用重构时，我总是力求得到灵活的解决方案。任何一个需求都让我提心吊胆地猜疑：在系统寿命期间，这个需求会导致怎样的变化？由于变更设计的代价非常高昂，所以我希望建造一个足够灵活、足够强固的解决方案，希望它能承受我所能预见的所有需求变化。问题在于：要建造一个灵活的解决方案，所需的成本难以估算。灵活的解决方案比简单的解决方案复杂许多，所以最终得到的软件通常也会更难维护 — 虽然它在我预先设想的??方向上，你也必须理解如何修改设计。如果变化只出现在一两个地方，那不算大问题。然而变化其实可能出现在系统各处。如果在所有可能的变化出现地点都建立起灵活性，整个系统的复杂度和维护难度都会大大提高。当然，如果最后发现所有这些灵活性都毫无必要，这才是最大的失败。你知道，这其中肯定有些灵活性的确派不上用场，但你却无法预测到底是哪些派不上用场。为了获得自己想要的灵活性，你不得不加入比实际需要更多的灵活性。
有了重构，你就可以通过一条不同的途径来应付变化带来的风险。你仍旧需要思考潜在的变化，仍旧需要考虑灵活的解决方案。但是你不必再逐一实现这些解决方案，而是应该问问自己：‘把一个简单的解决方案重构成这个灵活的方案有多大难度？’如果答案是“相当容易”（大多数时候都如此），那么你就只需实现目前的简单方案就行了。
重构可以带来更简单的设计，同时又不损失灵活性，这也降低了设计过程的难度，减轻了设计压力。一旦对重构带来的简单性有更多感受，你甚至可以不必再预先思考前述所谓的灵活方案 — 一旦需要它，你总有足够的信心去重构。是的，当下只管建造可运行的最简化系统，至于灵活而复杂的设计，唔，多数时候你都不会需要它。
劳而无获— Ron Jeffries
Chrysler Comprehensive Compensation（克莱斯勒综合薪资系统）的支付过程太慢了。虽然我们的开发还没结束，这个问题却已经开始困扰我们，因为它已经拖累了测试速度。
Kent Beck、Martin Fowler和我决定解决这个问题。等待大伙儿会合的时间里，凭着我对这个系统的全盘了解，我开始推测：到底是什么让系统变慢了？我想到数种可能，然后和伙伴们谈了几种可能的修改方案。最后，关于“如何让这个系统运行更快”，我们提出了一些真正的好点子。
然后，我们拿Kent的量测工具度量了系统性能。我一开始所想的可能性竟然全都不是问题肇因。我们发现：系统把一半时间用来创建“日期”实体（instance）。更有趣的是，所有这些实体都有相同的值。
于是我们观察日期的创建逻辑，发现有机会将它优化。日期原本是由字符串转换而生，即使无外部输入也是如此。之所以使用字符串转换方式，完全是为了方便键盘输入。好，也许我们可以将它优化。
于是我们观察日期怎样被这个程序运用。我们发现，很多日期对象都被用来产生“日期区间”实体（instance）。“日期区间”是个对象，由一个起始日期和一个结束日期组成。仔细追踪下去，我们发现绝大多数日期区间是空的！
处理日期区间时我们遵循这样一个规则：如果结束日期在起始日期之前，这个日期区间就该是空的。这是一条很好的规则，完全符合这个class的需要。采用此一规则后不久，我们意识到，创建一个“起始日期在结束日期之后”的日期区间，仍然不算是清晰的代码，于是我们把这个行为提炼到一个factory method（译注：一个着名的设计模式，见《Design Patterns》），由它专门创建“空的日期区间”。
我们做了上述修改，使代码更加清晰，却意外得到了一个惊喜。我们创建一个固定不变的“空日期区间”对象，并让上述调整后的factory method每次都返回该对象，而不再每次都创建新对象。这一修改把系统速度提升了几乎一倍，足以让测试速度达到可接受程度。这只花了我们大约五分钟。
我和团队成员（Kent和Martin谢绝参加）认真推测过：我们了若指掌的这个程序中可能有什么错误？我们甚至凭空做了些改进设计，却没有先对系统的真实情况进行量测。
我们完全错了。除了一场很有趣的交谈，我们什么好事都没做。
教训：哪怕你完全了解系统，也请实际量测它的性能，不要臆测。臆测会让你学到一些东西，但十有八九你是错的。

⑧ 软件开发方法

1：瀑布方法
所有软件方法的祖先是瀑布方法（waterfall methodology）。它之所以被称为瀑布方法是因为开发模块相互之间的依次流动，瀑布方法通过控制阀门的一系列活动组成。这些控制阀门决定一个给定的活动是否已经完成并且可以进入下一个活动。需求阶段处理决定了所有的软件需求。设计阶段决定整个系统的设计。代码在代码阶段编写。代码然后被测试。最后产品被发布。
对瀑布方法模型最基本的批评就是瀑布方法对于反馈事物发展状况耗时太长。软件的一些内容那个很容易被理解，而另一些内容则相反。因此，当用户对于手边出现的问题都没有很好理解的时候，开发人员试图先完成所有的需求（也就是说，将需求量化到实际的规格说明当中）是非常空难的。更进一步来说，如果在需求中出现一个错误，它将传播到设计阶段，传播到代码中等。同时一般不存在过程中返回的真正能力。因此，如果进入测试并且发现设计的一部分是无法工作的，那么就会进行修改并修补问题而交差，但是这种方法将会失去设计活动的所有上下文环境——你只是有目的地对系统权宜行事！
认识到这个问题后瀑布方法已经被修改成几种形式。例如螺旋式瀑布方法它继承并使用了多个瀑布模型。这种方法缩短了生命周期向下的时间；也就是说，为解决为题提供了迭代方案。
最终，大家无法脱离瀑布方法是因为它确实是合乎常规的方法。首先，这种方法可以决定将要构建的内容。接着，决定将要如何构建这些，下一步，世界构建这些内容。可以确保自己确实构建自己所需的东西（并且可以成功运行）。
2：统一过程
统一过程应用了基于处理系统首先考虑的最重要方面而实施的短期迭代开发。
开发一个寡欲各种用列（use case）的调查文档（也就是说，对用户与系统交互的简短描述），并且开始排除那些可能对整个系统成功造成风险的用列。只要适合，就可以在开发过程中添加或者删除用列。
统一过程的4个阶段定义如下：
初始(inception)：系统仍然处于决定系统内容的阶段——系统将要完成什么以及系统的边界是什么。如果系统能够很好的理解，那么这个阶段就非常短。
细化(Elaboration)：正在将体系结构的风险移至系统。一种表述该阶段的说法是，“你是否已经解决了所有难题？”或者“你知道如何完成你将要去完成的事情吗？”
构造（Construction）正在完成所有相关的用列来使系统为移交做好准备，也就是说，进入Beta版本。
移交（Transition）使系统通过它的最后发布阶段以及Beta版本。它可能包括软件的操作及维护。
这是一个关注于维护要素的敏捷过程，但是仍然采用了大量用例开发，间模等方面的传统实践。
3：极限编程：
极限编程的开发过程就是以代码为中心的方法。
让用户告知你一些有关系统是如何如用转的故事描述，基于故事相互之间的重要性来定制这些系统这样就可以为自己的团队提供一个故事集合，可以在一个给定的迭代中完成他们，大约两周时间——每周工作40个小时，你将团队划分，双人应付没一个故事，在代码被编写时提供确定数量的内建对等评审。你和你的同伴在编写自己代码的同时编写单元测试。在完成自己负责的那段代码后，将其拿到集成的机器上，放入代码基线，运行从所有人的代码中积累而成的单元测试。在完成iji负责的那段代码后，将会提供一个运行系统使用户可以评审来确保自己的工作满足他们的需要。
注意极限编程并没有将软件的设计设置成一个高级阶段。相反它认为那些最前端的设计对于整个系统开发不是很有帮助，并且随着实际开发的进行它最终还是被修改。
极限编程对于需要持续提供运行系统的软件卡发来说非常适用。当缺少用户介入或者项目规模很大时极限编程方法将会不好用，因为这时协调和设计活动实际上变得更重要了。
极限编程合理地考虑开发团体的能力，这样可以有效计划。

⑨ 什么是极限编程

极限编程(Extreme Programming，XP)是一门针对业务和软件开发的规则，它的作用在于将两者的力量集中在共同的、可以达到的目标上。它是以符合客户需要的软件为目标而产生的一种方法论，XP使开发者能够更有效的响应客户的需求变化，哪怕是在软件生命周期的后期。它强调，软件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分利用人的优势，而弱化人的缺点，突出了人在软件开发过程中的作用。极端编程属于轻量级的方法，认为文档、架构不如直接编程来的直接。

⑩ 什么极限编程

ExtremeProgramming（极限编程，简称XP）是由KentBeck在1996年提出的。KentBeck在九十年代初期与WardCunningham共事时，就一直共同探索着新的软件开发方法，希望能使软件开发更加简单而有效。Kent仔细地观察和分析了各种简化软件开发的前提条件、可能行以及面临的困难。1996年三月，Kent终于在为DaimlerChrysler所做的一个项目中引入了新的软件开发观念——XP。
XP是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
什么是软件开发

软件开发的内容是：需求、设计、编程和测试！

需求：不仅仅是用户需求，应该是开发中遇到的所有的需求。比如，你首先要知道做这个项目是为了解决什么问题；测试案例中应该输入什么数据……为了清楚地知道这些需求，你经常要和客户、项目经理等交流。

设计：编码前，肯定有个计划告诉你要做什么，结构是怎样等等。你一定要按照这个来做，否则可能会一团糟。

编程：如果在项目截止日，你的程序不能跑起来或达不到客户的要求，你就拿不到钱。

测试：目的是让你知道，什么时候算是完成了。如果你聪明，你就应该先写测试，这样可以及时知道你是否真地完成了。否则，你经常会不知道，到底有哪些功能是真正完成了，离预期目标还差多远。

软件开发中，客户和开发人员都有自己的基本权利和义务。
客户：
定义每个用户需求的商业优先级；
制订总体计划，包括用多少投资、经过多长时间、达到什么目的；
在项目开发过程中的每个工作周，都能让投资获得最大的收益；
通过重复运行你所指定的功能测试，准确地掌握项目进展情况；
能随时改变需求、功能或优先级，同时避免昂贵的再投资；能够根据各种变化及时调整项目计划；
能够随时取消项目；项目取消时，以前的开发工作不是一堆垃圾，已开发完的功能是合乎要求的，正在进行或未完成的的工作则应该是不难接手的。

开发人员：
知道要做什么，以及要优先做什么；
工作有效率；
有问题或困难时，能得到客户、同事、上级的回答或帮助；
对工作做评估，并根据周围情况的变化及时重新评估；
积极承担工作，而不是消极接受分配；
一周40小时工作制，不加班。

这就是软件开发，除此之外再还有其它要关心的问题！

灵巧的轻量级软件开发方法

一套软件开发方法是由一系列与开发相关的规则、规范和惯例。重量级的开发方法严格定义了许多的规则、流程和相关的文档工作。灵巧的轻量级开发方法，其规则和文档相对较少，流程更加灵活，实施起来相对较容易。

在软件工程概念出现以前，程序员们按照自己喜欢的方式开发软件。程序的质量很难控制，调试程序很繁琐，程序员之间也很难读懂对方写的代码。1968年，EdsgerDijkstra给CACM写了一封题为的信，软件工程的概念由此诞生。程序员们开始摒弃以前的做法，转而使用更系统、更严格的开发方法。为了使控制软件开发和控制其它产品生产一样严格，人们陆续制定了很多规则和做法，发明了很多软件工程方法，软件质量开始得到大幅度提高。随着遇到的问题更多，规则和流程也越来越精细和复杂。

到了今天，在实际开发过程中，很多规则已经难于遵循，很多流程复杂而难于理解，很多项目中文档的制作过程正在失去控制。人们试图提出更全面更好的一揽子方案，或者寄希望于更复杂的、功能更强大的辅助开发工具（CaseTools），但总是不能成功，而且开发规范和流程变得越来越复杂和难以实施。

为了赶进度，程序员们经常跳过一些指定的流程，很少人能全面遵循那些重量级开发方法。

失败的原因很简单，这个世界没有万能药。因此，一些人提出，将重量级开发方法中的规则和流程进行删减、重整和优化，这样就产生了很多适应不同需要的轻量级流程。在这些流程中，合乎实际需要的规则被保留下来，不必要的复杂化开发的规被抛弃。而且，和传统的开发方法相比，轻量级流程不再象流水生产线，而是更加灵活。

ExtremeProgramming（XP）就是这样一种灵巧的轻量级软件开发方法。

为什么称为“Extreme”（极限）

“Extreme”（极限）是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、做到最好；其它XP所不提倡的，则一概忽略（如开发前期的整体设计等）。一个严格实施XP的项目，其开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。

XP的软件开发是什么样

1极限的工作环境

为了在软件开发过程中最大程度地实现和满足客户和开发人员的基本权利和义务，XP要求把工作环境也做得最好。每个参加项目开发的人都将担任一个角色（项目经理、项目监督人等等）并履行相应的权利和义务。所有的人都在同一个开放的开发环境中工作，最好是所有人在同一个大房子中工作，还有茶点供应；每周40小时，不提倡加班；每天早晨，所有人一起站着开个短会；墙上有一些大白板，所有的Story卡、CRC卡等都贴在上面，讨论问题的时候可以在上面写写画画；下班后大家可以一起玩电脑游戏……。

2极限的需求

客户应该是项目开发队伍中的一员，而不是和开发人员分开的；因为从项目的计划到最后验收，客户一直起着很重要的作用。开发人员和客户一起，把各种需求变成一个个小的需求模块（UserStory），例如“计算年级的总人数，就是把该年级所有班的人数累加。”；这些模块又会根据实际情况被组合在一起或者被分解成更小的模块；它们都被记录在一些小卡片（StoryCard）上，之后分别被程序员们在各个小的周期开发中（Iteration，通常不超过3个星期）实现；客户根据每个模块的商业价值来指定它们的优先级；开发人员要做的是确定每个需求模块的开发风险，风险高的（通常是因为缺乏类似的经验）需求模块将被优先研究、探索和开发；经过开发人员和客户分别从不同的角度评估每个模块后，它们被安排在不同的开发周期里，客户将得到一个尽可能准确的开发计划；客户为每个需求模块指定验收测试（功能测试）。

每发布一次开发的软件（经过一个开发周期），用户都能得到一个可以开始使用的系统，这个系统全面实现了相应的计划中的所有需求。而在一些传统的开发模式中，无论什么功能，用户都要等到所有开发完成后才能开始使用。

3极限的设计

从具体开发的角度来看，XP内层的过程是一个个基于测试驱动的开发（TestDrivenDevelopment）周期，诸如计划和设计等外层的过程都是围绕这些展开的。每个开发周期都有很多相应的单元测试（UnitTest）。刚开始，因为什么都没有实现，所以所有的单元测试都是失败的；随着一个个小的需求模块的完成，通过的单元测试也越来越多。通过这种方式，客户和开发人员都很容易检验，是否履行了对客户的承诺。XP提倡对于简单的设计（SimpleDesign），就是用最简单的方式，使得为每个简单的需求写出来的程序可以通过所有相关的单元测试。XP强调抛弃那种一揽子详细设计方式（BigDesignUpFront），因为这种设计中有很多内容是你现在或最近都根本不需要的。XP还大力提倡设计复核（Review）、代码复核以及重整和优化（Refectory），所有的这些过程其实也是优化设计的过程；在这些过程中不断运行单元测试和功能测试，可以保证经过重整和优化后的系统仍然符合所有需求。

4极限的编程

既然编程很重要，XP就提倡两个人一起写同一段程序（PairProgramming），而且代码所有权是归于整个开发队伍（CollectiveCodeOwnership）。程序员在写程序和重整优化程序的时候，都要严格遵守编程规范。任何人都可以修改其他人写的程序，修改后要确定新程序能通过单元测试。

5极限的测试

既然测试很重要，XP就提倡在开始写程序之前先写单元测试。开发人员应该经常把开发好的模块整合到一起（ContinuousIntegration），每次整合后都要运行单元测试；做任何的代码复核和修改，都要运行单元测试；发现了BUG，就要增加相应的测试（因此XP方法不需要BUG数据库）。除了单元测试之外，还有整合测试，功能测试、负荷测试和系统测试等。所有这些测试，是XP开发过程中最重要的文档之一，也是最终交付给用户的内容之一。

XP中的重要惯例和规则

1项目开发小组（Team）

在XP中，每个对项目做贡献的人都应该是项目开发小组中的一员。而且，这个小组中必须至少有一个人对用户需求非常清晰，能够提出需求、决定各个需求的商业价值（优先级）、根据需求等的变化调整项目计划等。这个人扮演的是“客户”这个角色，当然最好就是实际的最终用户，因为整个项目就是围绕最终用户的需求而展开的。程序员是项目开发小组中必不可少的成员。小组中可以有测试员，他们帮助客户制订验收测试；有分析员，帮助客户确定需求；通常还有个Coach（教练），负责跟踪开发进度、解决开发中遇到的一些问题、推动项目进行；还可以又一个项目经理，负责调配资源、协助项目内外的交流沟通等等。项目小组中有这么多角色，但并不是说，每个人做的工作是别人不能插手或干预的，XP鼓励每个人尽可能地为项目多做贡献。平等相处，取长补短；这就是最好的XP开发小组。

2计划项目（PlanningGame）、验收测试、小规模发布（SmallReleases）

XP开发小组使用简单的方式进行项目计划和开发跟踪，并以次预测项目进展情况和决定未来的步骤。根据需求的商业价值，开发小组针对一组组的需求进行一系列的开发和整合，每次开发都会产生一个通过测试的、可以使用的系统。

计划项目

XP的计划过程主要针对软件开发中的两个问题：预测在交付日期前可以完成多少工作；现在和下一步该做些什么。不断的回答这两个问题，就是直接服务于如何实施及调整开发过程；与此相比，希望一开始就精确定义整个开发过程要做什么事情以及每件事情要花多少时间，则事倍功半。针对这两个问题，XP中又两个主要的相应过程：

软件发布计划（ReleasePlanning）。客户阐述需求，开发人员估算开发成本和风险。客户根据开发成本、风险和每个需求的重要性，制订一个大致的项目计划。最初的项目计划没有必要（也没有可能）非常准确，因为每个需求的开发成本、风险及其重要性都不是一成不变的。而且，这个计划会在实施过程中被不断地调整以趋精确。

周期开发计划（IterationPlanning）。开发过程中，应该有很多阶段计划（比如每三个星期一个计划）。开发人员可能在某个周期对系统进行内部的重整和优化（代码和设计），而在某个周期增加了新功能，或者会在一个周期内同时做两方面的工作。但是，经过每个开发周期，用户都应该能得到一个已经实现了一些功能的系统。而且，每经过一个周期，客户就会再提出确定下一个周期要完成的需求。在每个开发周期中，开发人员会把需求分解成一个个很小的任务，然后估计每个任务的开发成本和风险。这些估算是基于实际开发经验的，项目做得多了，估算自然更加准确和精确；在同一个项目中，每经过一个开发周期，下一次的估算都会有更过的经验、参照和依据，从而更加准确。这些简单的步骤对客户提供了丰富的、足够的信息，使之能灵活有效地调控开发进程。每过两三个星期，客户总能够实实在在地看到开发人员已经完成的需求。在XP里，没有什么“快要完成了”、“完成了90%”的模糊说法，要不是完成了，要不就是没完成。这种做法看起来好象有利有弊：好处是客户可以马上知道完成了哪些、做出来的东西是否合用、下面还要做些什么或改进什么等等；坏处是客户看到做出来的东西，可能会很不满意甚至中止合同。实际上，XP的这种做法是为了及早发现问题、解决问题，而不是等到过了几个月，用户终于看到开发完的系统了，然后才告诉你这个不行、那个变了、还要增加
哪个内容等等。

验收测试

客户对每个需求都定义了一些验收测试。通过运行验收测试，开发人员和客户可以知道开发出来的软件是否符合要求。XP开发人员把这些验收测试看得和单元测试一样重要。为了不浪费宝贵的时间，最好能将这些测试过程自动化。

频繁地小规模发布软件（SmallReleases）

每个周期（Iteration）开发的需求都是用户最需要的东西。在XP中，对于每个周期完成时发布的系统，用户都应该可以很容易地进行评估，或者已经能够投入实际使用。这样，软件开发对于客户来说，不再是看不见摸不着的东西，而是实实在在的。XP要求频繁地发布软件，如果有可能，应该每天都发布一个新版本；而且在完成任何一个改动、整合或者新需求后，就应该立即发布一个新版本。这些版本的一致性和可靠性，是靠验收测试和测试驱动的开发来保证的。

3简单设计，PairProgramming，测试驱动开发，重整和优化

XP程序员不但做为一个开发小组共同工作，还以两个人为一个小开发单元编写同一个程序。开发人员们进行简单的设计，编写单元测试后再编写符合测试要求的代码，并在满足需求的前提下不断地优化设计。

简单设计

XP中让初学者感到最困惑的就是这点。XP要求用最简单的办法实现每个小需求，前提是按照这些简单设计开发出来的软件必须通过测试。这些设计只要能满足系统和客户在当下的需求就可以了，不需要任何画蛇添足的设计，而且所有这些设计都将在后续的开发过程中就被不断地重整和优化。

在XP中，没有那种传统开发模式中一次性的、针对所有需求的总体设计。在XP中，设计过程几乎一直贯穿着整个项目开发：从制订项目的计划，到制订每个开发周期（Iteration）的计划，到针对每个需求模块的简捷设计，到设计的复核，以及一直不间断的设计重整和优化。整个设计过程是个螺旋式的、不断前进和发展的过程。从这个角度看，XP是把设计做到了极致。

PairProgramming

XP中，所有的代码都是由两个程序员在同一台机器上一起写的——这是XP中让人争议最多、也是最难实施的一点。这保证了所有的代码、设计和单元测试至少被另一个人复核过，代码、设计和测试的质量因此得到提高。看起来这样象是在浪费人力资源，但是各种研究表明事实恰恰相反。——这种工作方式极大地提高了工作强度和工作效率。

很多程序员一开始是被迫尝试这点的（XP也需要行政命令的支持）。开始时总是不习惯的，而且两个人的效率不会比一个人的效率高。这种做法的效果往往要坚持几个星期或一两个月后才能很显着。据统计，在所有刚开始PairProgramming的程序员中，90%的人在两个月以后都很认为这种工作方式更加高效。

项目开发中，每个人会不断地更换合作编程的伙伴。因此，PairProgramming不但提高了软件质量，还增强了相互之间的知识交流和更新，增强了相互之间的沟通和理解。这不但有利于个人，也有利于整个项目、开发队伍和公司。从这点看，PairProgramming不仅仅适用于XP，也适用于所有其它的软件开发方法。

测试驱动开发

反馈是XP的四个基本的价值观之一——在软件开发中，只有通过充分的测试才能获得充分的反馈。XP中提出的测试，在其它软件开发方法中都可以见到，比如功能测试、单元测试、系统测试和负荷测试等；与众不同的是，XP将测试结合到它独特的螺旋式增量型开发过程中，测试随着项目的进展而不断积累。另外，由于强调整个开发小组拥有代码，测试也是由大家共同维护的。即，任何人在往代码库中放程序（CheckIn）前，都应该运行一遍所有的测试；任何人如果发现了一个BUG，都应该立即为这个BUG增加一个测试，而不是等待写那个程序的人来完成；任何人接手其他人的任务，或者修改其他人的代码和设计，改动完以后如果能通过所有测试，就证明他的工作没有破坏愿系统。这样，测试才能真正起到帮助获得反馈的作用；而且，通过不断地优先编写和累积，测试应该可以基本覆盖全部的客户和开发需求，因此开发人员和客户可以得到尽可能充足的反馈。

重整和优化(Refactoring)

XP强调简单的设计，但简单的设计并不是没有设计的流水帐式的程序，也不是没有结构、缺乏重用性的程序设计。开发人员虽然对每个USERSTORY都进行简单设计，但同时也在不断地对设计进行改进，这个过程叫设计的重整和优化（Refactoring）。这个名字最早出现在MartinFowler写的《Refactoring:》这本书中。

Refactoring主要是努力减少程序和设计中重复出现的部分，增强程序和设计的可重用性。Refactoring的概念并不是XP首创的，它已经被提出了近30年了，而且一直被认为是高质量的代码的特点之一。但XP强调，把Refactoring做到极致，应该随时随地、尽可能地进行Refactoring，只要有可能，程序员都不应该心疼以前写的程序，而要毫不留情地改进程序。当然，每次改动后，程序员都应该运行测试程序，保证新系统仍然符合预定的要求。

4频繁地整合，集体拥有代码（CollectiveCodeOwnership），编程规范

XP开发小组经常整合不同的模块。为了提高软件质量，除了测试驱动开发和PairProgramming以外，XP要求每个人的代码都要遵守编程规范，任何人都可以修改其他人写的代码，而且所有人都应该主动检查其他人写的代码。

频繁地整合（Integration）

在很多项目中，开发人员往往很迟才把各个模块整合在一起。在这些项目中，开发人员经常在整合过程中发现很多问题，但不能肯定到底是谁的程序出了问题；而且，只有整合完成后，开发人员才开始稍稍使用整个系统，然后就马上交付给客户验收。对于客户来说，即使这些系统能够通过终验收测试，因为使用时间短，客户门心里并没有多少把握。

为了解决这些问题，XP提出，整个项目过程中，应该频繁地，尽可能地整合已经开发完的USERSTORY（每次整合一个新的USERSTORY）。每次整合，都要运行相应的单元测试和验收测试，保证符合客户和开发的要求。整合后，就发布一个新的应用系统。这样，整个项目开发过程中，几乎每隔一两天，都会发布一个新系统，有时甚至会一天发布好几个版本。通过这个过程，客户能非常清楚地掌握已经完成的功能和开发进度，并基于这些情况和开发人员进行有效地、及时地交流，以确保项目顺利完成。

集体拥有代码（CollectiveCodeOwnership）

在很多项目开发过程中，开发人员只维护自己的代码，而且很多人不喜欢其他人随意修改自己的代码。因此，即使可能有相应的比较详细的开发文档，但一个程序员却很少、也不太愿意去读其他程序员的代码；而且，因为不清楚其他人的程序到底实现了什么功能，一个程序员一般也不敢随便改动其他人的代码。同时，因为是自己维护自己的代码，可能因为时间紧张或技术水平的局限性，某些问题一直不能被发现或得到比较好的解决。针对这点，XP提倡大家共同拥有代码，每个人都有权利和义务阅读其他代码，发现和纠正错误，重整和优化代码。这样，这些代码就不仅仅是一两个人写的，而是由整个项目开发队伍共同完成的，错误会减少很多，重用性会尽可能地得到提高，代码质量是非常好。

为了防止修改其他人的代码而引起系统崩溃，每个人在修改后都应该运行测试程序。（从这点，我们可以再次看到，XP的各个惯例和规则是怎样有机地结合在一起的。）

编程规范

XP开发小组中的所有人都遵循一个统一的编程标准，因此，所有的代码看起来好像是一个人写的。因为有了统一的编程规范，每个程序员更加容易读懂其他人写的代码，这是是实现CollectiveCodeOwnership的重要前提之一。

5Metaphor（系统比喻），不加班

XP过程通过使用一些形象的比喻让所有人对系统有个共同的、简洁的认识。XP认为加班是不正常的，因为这说明关于项目进度的估计和安排有问题。

Metaphor（系统比喻）

为了帮助每个人一致清楚地理解要完成的客户需求、要开发的系统功能，XP开发小组用很多形象的比喻来描述系统或功能模块是怎样工作的。比如，对于一个搜索引擎，它的Metaphor可能就是“一大群蜘蛛，在网上四处寻找要捕捉的东西，然后把东西带回巢穴。”

不加班

大量的加班意味着原来的计划是不准确的，或者是程序远不清楚自己到底什么时候能完成什么工作。而且，开发管理人员和客户也因此无法准确掌握开发速度；开发人员也因此非常疲劳。XP认为，如果出现大量的加班现象，开发管理人员（比如Coach）应该和客户一起确定加班的原因，并及时调整项目计划、进度和资源。

XP中一些基本概念的简介

UserStory：开发人员要求客户把所有的需求写成一个个独立的小故事，每个只需要几天时间就可以完成。开发过程中，客户可以随时提出新的UserStory，或者更改以前的UserStory。

StoryEstimates和开发速度：开发小组对每个UserStory进行估算，并根据每个开发周期（Iteration）中的实际情况反复计算开发速度。这样，开发人员和客户能知道每个星期到底能开发多少UserStory。

ReleasePlan和ReleaseScope：整个开发过程中，开发人员将不断地发布新版本。开发人员和客户一起确定每个发布所包含的UserStory。

Iteration（开发周期）和IterationPlan：在一个Release过程中，开发人员要求客户选择最有价值的UserStory作为未来一两个星期的开发内容。

TheSeed：第一个开发周期（Iteration）完成后，提交给客户的系统。虽然这不是最终的产品，但它已经实现了几个客户认为是最重要的Story，开发人员将逐步在其基础上增加新的模块。

ContinuousIntegration（整合）：把开发完的UserStory的模块一个个拼装起来，一步步接近乃至最终完成最终产品。

验收测试（功能测试）：对于每个UserStory，客户将定义一些测试案例，开发人员将使运行这些测试案例的过程自动化。

UnitTest（单元测试）：在开始写程序前，程序员针对大部分类的方法，先写出相应的测试程序。

Refactoring(重整和优化)：去掉代码中的冗余部分，增加代码的可重用性和伸缩性。

小结

XP的一个成功因素是重视客户的反馈——开发的目的就是为了满足客户的需要。XP方法使开发人员始终都能自信地面对客户需求的变化。XP强调团队合作，经理、客户和开发人员都是开发团队中的一员。团队通过相互之间的充分交流和合作，使用XP这种简单但有效的方式，努力开发出高质量的软件。XP的设计简单而高效；程序员们通过测试获得客户反馈，并根据变化修改代码和设计，他们总是争取尽可能早地将软件交付给客户。XP程序员能够勇于面对需求和技术上的变化。

XP很象一个由很多小块拼起来的智力拼图，单独看每一小块都没有什么意义，但拼装好后，一幅美丽的图画就会呈现在你面前。