极限编程(XP)：将所有优势推至极致
2020-01-03
来源：技术大V公众号
正当前的迭代计划，还要重新修正发布计划，因为有些包含在原先发布计划中的功能会无法交付。
测试驱动开发(Test Driven Development)
简称TDD，又译测试先行。在写某个模块之前，先写这个模块的单元测试。在没有任何代码情况下，运行单元测试，确认不通过。然后写这个模块代码，代码完成后再运行单元测试确认通过，然后再考虑现有代码是否有需要重构或精简的地方。这样的好处在于添加的代码有着完全的单元测试覆盖，以后改动代码如果破坏了现在的功能会立刻被发现。先写单元测试也迫使开发人员提前思考这个模块失效的各种可能。测试驱动开发和结对编程一起，通常被认为是极限编程最具特色的标志性做法。
现场客户(Onsite Customer)
这里的客户是指软件的用户，真正的使用者(不一定是购买者，比如企业订制了一套大厅信息查询系统，购买者是该企业IT部门负责人，但他并不是这个系统的使用者)。用户应该全程参与开发，以随时回答开发团队的问题，缩短反馈时间，比如正在开发一个汽车销售系统，团队内就应该加入一个车行里的销售人员，来随时获取用户反馈，修改功能或开发方向。
持续过程(Continuous Process)
持续集成(Continuous Integration)
每完成部分代码就将它集成到系统中去，进行频繁小量的集成，而不是在本地代码累积大量改动之后再做一个单次特别大的集成。每次集成后自动编译build，运行相应的自动测试，检测是否有问题。比起单次大量集成，这样每次集成所需改动较小，不用花费大量时间进行集成，可以更快地发现新加入代码的问题，在发现问题之后也更容易限定范围，找出问题所在。持续集成在今天几乎已经是每个开发团队的标准做法，并不仅仅局限于使用极限编程的团队。但在极限编程刚提出的年代，持续集成还是很先进的做法。
代码重构(Refactoring)
极限编程提倡简单设计，仅仅写满足当前需要的最简洁的代码，然而从扩展性上来看，最简代码却不一定是最优的设计。时间长了之后，不同的代码堆积起来也可能出现问题，需要重构。比如在几个不同的方法里都发现了类似的一段逻辑，这样就应该把这段逻辑单独抽出来作为一个方法，让其他方法传递不同的参数调用它。当然，代码重构的实践很早就被极为广泛的使用，并不是极限编程的专属。
小型发布(Small Release)
频繁地发布新版本，每个版本的改动较小，这样有两个好处：用户可以更快地拿到部分功能，频繁地发布会增强用户的信心，建立起信任感。我们可以更快的从发布版本中得到实用中的用户反馈。
共享认知(Shared Understanding)
编码标准(Coding Standard)
团队制定和使用同一编码标准，对代码的风格、版式等作出规定。这样团队里每个成员都能比较容易地理解其他部分的代码，这也为接下来将提到的代码集体共有创造了条件。
简单设计(Simple Design)
仅用最简洁的代码来实现当前的需求，而不考虑未来可能的其他需要。这样做的原因是极限编程认为变化是经常的和难以预测的，我们现在预测的未来需求很可能随着种种变化而不会出现，所以干脆就不考虑未来的可能性，等它真正出现了再说。极限编程里有一个YAGNI的概念，即You aren't gonna need it(你将不会需要)的缩写。就是说你现在如果提前实现一些将来可能用到的东西，到时候你其实并不会用到它们，所以仅仅实现当前必需的要求就好。简单设计和上面提到的代码重构其实是一体两面的。不同模块简单设计的累积会让系统产
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
