我觉得最经典的两句话，欢迎大家续接！！！

什么叫做对类型的描述

关于第一句，本人不是很苟同，XP工程方法实际的前提是需求是不断变化的，因为我无法预料需求如何变化，所以我加快开发循环，甚至是每天一次设计 编程 测试，再和用户确认。

妄图通过设计将用户需求包容，是不现实的，也会延误工程进度，也很少有人有这样的能力。

只有设计体现scalable,具有动态扩展性，然后通过反复refactory，才能将我们的产品开发得越来越符合客户需求，是客户心目中真正所想的那样。

我认为下面一句比较合理：

“计划没有变化快，承认变化是唯一不变的真理，重视refactory甚至re-Design, 使用XP工程法，才能让你跟上变化的脚步。”

xp并不是成功的保证，
xp是developer-oriented的,
不是requirement-oriented的，
xp的快速迭代和现场客户只会使用户精疲力尽，
在初期写出effective的use case会事半功倍

当然，如果“在初期写出effective的use case会事半功倍”，但是实际情况是能够吗？很多人责怪没有高级的系统分析师，那么难道没有这些神仙，我们就不能够寻找另外的办法。

XP完全可以，而且在我们实践中用得很多，类似我们以前讲的原型法，XP+OO+Refactory可以使我们脱离传统的RUP方法，真正开发出符合客户需求的项目产品。

xp会给人以错觉，
就是只用编程，
不用写文档，
使用use case不是指瀑布方式，
而是一种正确的文档方式。

软件产品中99%的错误是由于程序员粗心所造成的

我怎么觉得这句话不对那，我认为大部分的错误是由于设计的缺陷造成的。

软件产品中99%的错误是项目管理不善导致，项目管理不善的99%问题是没有找到一个切实可行的工程方法。

面向对象的应用应该向修改关闭，向配置开放。

就是当需求改变后，我们的程序应该可以通过配置进行模块的增加，功能的改进等！而不需要修改相关的源代码！

能不能详细讲讲工程方法？

//面向对象的应用应该向修改关闭，向配置开放。
//就是当需求改变后，我们的程序应该可以通过配置进行模块的增加，功
//能的改进等！而不需要修改相关的源代码！

YAGNI--考虑的太多不一定是好事，尤其就项目而言是要作成本控制的，
如果是作framework就不一样了

在对需求，设计，可行的工程方法都进行确认后，软件产品中99%的错误是由程序员的粗心所产生的。

其实我们把项目寄放在一些已经存在的应用中就好了！象ofbiz，至少我们的可扩展性会很高的！