砖头*XP*简单设计 frankcai
扔块砖头先，
大牛们多砸些玉过来，好像小辈开开眼：）
XP主张简单设计，在extreme programming explained 里面说到
原因是传统软件工程认为应付变化的成本随时间指数增长。
xp认为现代软件开发过程中这条定理已经不成立了，
因为采用了面向对象软件设计方法和设计模式之类的方法就可以，
我觉得这应该不太可能吧？
即使是面向对象，即使是很好的运用模式，
这最多也 是在一定程度上可以从容应付变化吧？
如果是需求变的太大，再怎么面向对象也是没用的吧？
不知道实际中是怎么样的？
然而我还是非常同意简单设计，原因是既然需求总是多变，
我们不可能在一开始就把需求真正捕捉到，与其把大量的时间花在
对那些错误需求的设计，实现，测试中，还不如开始的时候简单一点，
把最核心，最不可能变的那部分做出来，然后再用它捕捉需求，对它进行修改，也许
这时候我们会觉得要花很多时间，但是其实在前面我们节省了很多时间了，
而且总的看来，我们浪费在错误需求上的时间少了，节省的时间就多了，
这可能也可以说是原型方法吧。
另外，在技术风险比较大的时候，（比如我们学生用新学的东西做事）
开始过多的考虑细节，试图一次把问题全部搞定，
往往会降低效率，比如一点一点做来的好，当然，这是在整体的结构已经清楚的情况下。
(这一点是我自己实际的体会：）
以上拙见，诸君见笑。
调侃pair programming adoal
1）A是大牛，B是入门级，
1.1)A在coding,B在旁边看，看了半天，B总看不懂。此时B的选择：
1.1.1)心不在焉，去想昨天的艳遇了
1.1.2）不断地问A写的代码是什么意思，A最终不堪其扰，掏出个苍
蝇拍把B打趴下
1.2)B在coding，A在旁边看，看了半天，觉得代码臭不可挡。此时A
的选择：
1.2.1)装看不见，回头重写
1.2.2)A被代码的smell薰得怒不可遏，掏出个苍蝇拍把B打昏，然后
卷起袖子自己上阵
1.2.3)不断对B说应该如何如何，B终不堪其辱，奋而掏出苍蝇拍把A
拍死
2) A与B水平相当
2.1)意见相合
2.1.1）看的觉得好无聊，也想艳遇去了
2.1.2）看的坚守岗位，及时纠正了若干打字错误
2.2）意见不合
2.2.1）二人属理论派，引经据典，争执不下，最后各掏出一只苍蝇
拍互拍，没倒下的写程序
2.2.2）二人属实力派，各自去做各自的实现，实现完了发现还是公
说公的好，婆说婆的好。不过在实际的场合中，这也许不多见，毕竟
事实摆在眼前，一般还是可以得出统一意见的（如果不是某些技术以
外的原因在驱使的话）。但这个好象就不能算pair programming了吧？
