简单二字我想不会有人不喜欢，尤其是当它和软件开发联系在一起时，但程序员的生活真的能“简单”吗？
我发现XP教条中的简单可以体现在如下方面：设计、代码、文档、发布。
“设计简单”意指应用程序的功能仅满足客户当前的需求，也就是说对于用户将来可能会有的需求完全不予考虑，这一思想来源于XP在对待客户需求的态度上和传统开发方式的本质区别。传统的工程化的软件开发过程强调初始设计的重要性（这一点在有过渡设计倾向的日本软件尤其突出），然而用户的需求却不可能一成不变，这一实践不得不预料、揣测可能的需求变更，而且十分恐惧用户的需求变更，因为一旦变更，不得不打回设计部门，重新设计、重新文档、重新编码、重新测试，多数工程化的软件开发根本受不了这样的反复，所以至少在中国经常性发生的情况是不更新文档、不写测试，仅仅单方面地修改代码，其间也顾及不了这一代码修改会给整个系统带来怎样的影响，反正随便搞点数据一测了事。代码和文档的差距也就此越来越大，最终参考价值全无，软件的质量也在这样的反反复复中一天天地衰败。反观XP，则欢迎需求的变更，即使是在开发后期也同样欢迎，因为这是XP的优势所在。XP的理念是与客户协作（这里的客户并是为软件付账的人，而是真正要使用软件的人），和用户的关系也是互利互惠，彼此关怀帮助的，满足客户变化的需求是软件开发人员的职责所在，如果开发出来的软件不能迎合用户的需求，那做出来还有什么意义呢。所以XP从来不排斥需求变更，但能做到这一点，和XP的诸多特性都有密切的联系，所谓环环相扣。
“代码简单”是由程序可读性引出的教条，XP希望每个方法都只做一件事，并拥有一个恰如其分的能说明其功能的名称，也就是说不仅是为了代码重用而抽取（Extract）方法。当然在代码编写的初期很难预料到哪些代码可以抽取出来，所以XP的重构思想是代码简单的保证，这在下一篇文章中详细说明。
“文档简单”是相对于目前工程化软件开发的重量级文档而言的。重量级文档的产生源于企业对人员流动风险的恐惧，希望把所有的信息都实实在在地落实到书面上，这样无论换了谁来开发，都不会使项目瘫痪。可惜事与愿违，海量的文档反而束缚了软件开发的进程，不仅减缓了开发速度，降低了开发效率，众多与代码不同步的文档反而容易使人产生错误的判断，失去了文档应有的价值。XP认为，软件开发最主要的还是软件本身，即实实在在运行着的代码，而不是对用户毫无意义的文档。开发人员的主要精力应该投入到编写和完善代码上，而不是大量的文书工作。那如何规避人员流动的风险呢？一方面通过结队开发（前篇文章中有详细说明）大大降低人员流动带来的冲击，另一方面通过完善的测试用例和程序内（inline）注释，使开发人员迅速掌握代码的逻辑和实现方式。至于文档，XP需要的是有价值的精简的文档，诸如对系统架构的说明、数据库的说明、模块功能的概览等等，至于细致入微的设计和实施文档，XP都予以拒绝。
“发布简单”这一用词可能不太准确，XP继承了敏捷开发（Agile Development）的思想，采用迭代开发的模式，希望团队尽可能早地、尽可能频繁地发布软件。统计发现第一个版本发布得越早，最终版本的完善程度越高。XP推荐采用2周到1个月做为一个迭代周期。开发人员要摆脱英雄主义思想，不要设想给客户什么惊喜，越早、越频繁地和客户交换意见，给客户使用最近的版本，最终越有可能做出完善的产品，并少走弯路，少做无用功。当然为了能达到和客户充分交流的目的，XP的现场客户概念（On Site Customer）又变得十分迫切，即客户在开发现场和程序员一通工作，有任何问题便可马上交流。可惜这一点目前很难做到，尤其是对软件公司而言。但对于很多企业具有开发能力的IT部门，这样的实践还是有相当可行性的。
“简单”是XP实践的中相当重要的因素，也是对传统软件开发方式的一大挑战，根据我的亲身体验，“简单”的确能为程序员的生活带来更多幸福的感觉。
我发现XP教条中的简单可以体现在如下方面：设计、代码、文档、发布。
“设计简单”意指应用程序的功能仅满足客户当前的需求，也就是说对于用户将来可能会有的需求完全不予考虑，这一思想来源于XP在对待客户需求的态度上和传统开发方式的本质区别。传统的工程化的软件开发过程强调初始设计的重要性（这一点在有过渡设计倾向的日本软件尤其突出），然而用户的需求却不可能一成不变，这一实践不得不预料、揣测可能的需求变更，而且十分恐惧用户的需求变更，因为一旦变更，不得不打回设计部门，重新设计、重新文档、重新编码、重新测试，多数工程化的软件开发根本受不了这样的反复，所以至少在中国经常性发生的情况是不更新文档、不写测试，仅仅单方面地修改代码，其间也顾及不了这一代码修改会给整个系统带来怎样的影响，反正随便搞点数据一测了事。代码和文档的差距也就此越来越大，最终参考价值全无，软件的质量也在这样的反反复复中一天天地衰败。反观XP，则欢迎需求的变更，即使是在开发后期也同样欢迎，因为这是XP的优势所在。XP的理念是与客户协作（这里的客户并是为软件付账的人，而是真正要使用软件的人），和用户的关系也是互利互惠，彼此关怀帮助的，满足客户变化的需求是软件开发人员的职责所在，如果开发出来的软件不能迎合用户的需求，那做出来还有什么意义呢。所以XP从来不排斥需求变更，但能做到这一点，和XP的诸多特性都有密切的联系，所谓环环相扣。
“代码简单”是由程序可读性引出的教条，XP希望每个方法都只做一件事，并拥有一个恰如其分的能说明其功能的名称，也就是说不仅是为了代码重用而抽取（Extract）方法。当然在代码编写的初期很难预料到哪些代码可以抽取出来，所以XP的重构思想是代码简单的保证，这在下一篇文章中详细说明。
“文档简单”是相对于目前工程化软件开发的重量级文档而言的。重量级文档的产生源于企业对人员流动风险的恐惧，希望把所有的信息都实实在在地落实到书面上，这样无论换了谁来开发，都不会使项目瘫痪。可惜事与愿违，海量的文档反而束缚了软件开发的进程，不仅减缓了开发速度，降低了开发效率，众多与代码不同步的文档反而容易使人产生错误的判断，失去了文档应有的价值。XP认为，软件开发最主要的还是软件本身，即实实在在运行着的代码，而不是对用户毫无意义的文档。开发人员的主要精力应该投入到编写和完善代码上，而不是大量的文书工作。那如何规避人员流动的风险呢？一方面通过结队开发（前篇文章中有详细说明）大大降低人员流动带来的冲击，另一方面通过完善的测试用例和程序内（inline）注释，使开发人员迅速掌握代码的逻辑和实现方式。至于文档，XP需要的是有价值的精简的文档，诸如对系统架构的说明、数据库的说明、模块功能的概览等等，至于细致入微的设计和实施文档，XP都予以拒绝。
“发布简单”这一用词可能不太准确，XP继承了敏捷开发（Agile Development）的思想，采用迭代开发的模式，希望团队尽可能早地、尽可能频繁地发布软件。统计发现第一个版本发布得越早，最终版本的完善程度越高。XP推荐采用2周到1个月做为一个迭代周期。开发人员要摆脱英雄主义思想，不要设想给客户什么惊喜，越早、越频繁地和客户交换意见，给客户使用最近的版本，最终越有可能做出完善的产品，并少走弯路，少做无用功。当然为了能达到和客户充分交流的目的，XP的现场客户概念（On Site Customer）又变得十分迫切，即客户在开发现场和程序员一通工作，有任何问题便可马上交流。可惜这一点目前很难做到，尤其是对软件公司而言。但对于很多企业具有开发能力的IT部门，这样的实践还是有相当可行性的。
“简单”是XP实践的中相当重要的因素，也是对传统软件开发方式的一大挑战，根据我的亲身体验，“简单”的确能为程序员的生活带来更多幸福的感觉。
