解读极限编程的十二大原则——前言

解读极限编程的十二大原则

前言

作为软件开发者，我们很羡慕那些商业软件的开发人员，比如Windows，因为感觉它们的开发者很幸福，不会说哪个用户提出来某个功能就马上去修改程序，甚至当用户使用这些软件的时候出现了问题首先都会怀疑是不是自己的操作出了问题。

不幸的是我们很多开发人员从事的是行业软件、定制软件的开发，总会听到定制的声音，总会感到需求的不断改变，总会感到软件永远没有稳定下来的日子，总会感到修改的日子没有尽头。管理人员也很头疼，按照研发规范的要求，开发人员必须在编写代码的同时编写设计文档，然而不断的修改最终使得文档的编写成了累赘，于是：

n         我们的文实一致性得不到保证

n         我们的设计文档成了“废物”，甚至误导

n         我们的新员工花费了大量的时间阅读文档却发现不如去直接读程序

n         我们加班却总是发现有永远干不完的事情

n         ……

传统软件工程中对软件开发过程的定义在这种需求变化频繁、却要求快速交付的软件开发实践中显得那么的无助。大家都在困惑，在寻找出路，于是，当我第一次在ThoughtWorks的网站上看到关于极限开发的理念时，很激动，开始了关于极限开发的学习，也尝试根据自己的理解在工作中实践。网上关于极限开发的争论一直都很多，关于这套理论并不是一切问题的终结者，但是随着学习和思考的深入，我日益感觉到极限开发理念为我们提供了一个新的思维方式：原来，我们可以这样思考问题！比喻的说就是我们的开发模式如思想般已经僵化了，需要一种新的声音来灌输新的活力，只有思维活跃了，才能创新，作为开发人员不光是技术需要创新，思维更要创新。更重要的是，我觉得对于硬件开发，极限开发理念中一样有其可以借鉴的地方。

 

希望能够通过根据自己的体验解读有关极限编程的十二大原则，来吸引更多的志同道合者一起对我们的工作进行思考和改良。

 

附录：极限编程的十二大原则

1.计划的制定：包括客户选择的项目大小、程序功能的优先级、各个版本的合成和发布日期。

2.小版本：用最少的代码工作量带来最大的业务价值。

3.简单设计：通过所有测试，没有重复和费解的逻辑代码，简单的设计能保证代码的简单。

4.测试：一个功能存在的前提是有一个测试能够验证它，任何有被破坏的可能的代码就必须有一个对应的测试。

5.持续整合：大量减少在整合中耗费的时间，减少团队开发问题。

6.重构：确保加入新功能后代码仍保持简单，从而保证简单的代码仍然能够运行所有的测试。

7.配对编程：提供持续的信息反馈和确保正在编程的人进行重构、测试和遵守编码标准，实现代码共享目的。

8.代码共享：在通过测试的前提下，任何一个人都能够对系统做出修改。

9.每周只工作40小时：充分利用你的时间，一个星期工作40小时已经足够了。

10.现场客户：讨论，使用程序员和客户都能够的语言描述功能。

11.隐喻：普通语言和术语的集合，用来预见项目中的功能。

12.编码标准：遵守编码标准，让其它程序员明白代码，减少不必要的沟通。