上午刚写了《践行结对编程》，下午就看到JavaEye上emarket写的《XP的反省-Pair Programming》，他认为“pair programming给我带来的的忧大于喜，缺点大于有点”。其中提到Pair表现出高生产力是在实验条件下得出的，而实验的条件是：
- Pair的人必须对等 （同班同学）。
- Pair的人必须全力以赴 (同学们，老师在做实验哦，不要走神！)。
- Pair的人必须对要解决的问题有相同（或相近）的认知 。
其实这和我在《践行结对编程》总结的属于同一个观点；
- Pair的人必须对等：水平较低的人容易产生依赖心理，所以需要鼓励水平低的人主动，而水平高的应该以指导和沟通为主。
- Pair的人必须全力以赴：结对其实本来会使人全力以赴，两人一起做事情的时候，没有走神儿的条件。
- Pair的人必须对要解决的问题有相同（或相近）的认知：结对的两个人对结对的任务都必须实现有了解做到心中有数。而结对时也要经过讨论，达成共识，然后方能动手写程序。
“pair on everything则是对人性的强奸”，这话有点儿过了，估计是作者的公司实施的问题，这点从他们“老板的原则是绝不让任何一个知识点停留在一个人的脑瓜里”，可以看出一点。pair on everything是不太合适的，这点儿Henrik Kniberg在《Scrum and XP from the Trenches》中也有提到。我们团队在操作的时候也曾经要求pair on everything，后来成员有意见，慢慢的变更了方案。但是pair on programm还是有好处的，这点儿也是我们团队实践后得出的共同结论。
说到底，结对只是一种方法，没有对不对，只有合适不合适。以前用瀑布模式的时候也有人骂，现在敏捷有人骂，没有什么好奇怪的。其实是这些方法不适合或者实施的时候没有抓住精髓，而是形式化了。
管理是一门艺术，软件工程也是。为什么满大街都是讲管理的书，而因为管理不好倒闭的公司仍然满大街都是？因为不适合、因为不变通，所以纵然有再好的软件工程学方法，还是会有失败的项目。
一直认为管理和设计一样，没有好坏，无非“取舍”二字。就像高中有道经典的物理学题目：子弹打木块。可以用速度解、可以用能量解，大学学了微积分之后还可以用微积分解，没有哪一种解法好那一种不好，只是合不合适的问题。
所以要学习各种解法、了解他们的优点缺点和适用范围，不同的情景采用不同的方法，甚至混合使用多种方法。
不过，最重要的还是——理解问题的本质！
