上周我们的product刚刚release了一个新的version．看了change log．大概有一半都是砍feature，砍configuration option．　

我们一直都是用ＸＰ开发，但是回过头来，我们的configuration的确太麻烦。我的新版本的installation guide从原来的10 page缩减成1 page。虽然颇有成就感，但是不时地要反省一下　一开始我们为什么要那么做。　

归其原因不外乎

１。现在砍feature是因为customer的无知（我们不是真的customer，　是proxy customer 这个东西本事就是个自欺欺人的名词 更多的可看我的另一篇讨论 自欺欺人的proxy customer ）

２。现在砍configuration是因为developer误解了什么是The Simplest Thing That Could Possibly Work ．　

那我们现在就来说说2吧，当初有这样一个requirement

Story 1:  I want a module that can read all the property files in a particular location (file system). And return a  Map<String, Properties>. The Key will be the file name, and the value will the properties in the file.

developer拿到之后，simple design吗，那我就设计一个 PropertyLoader 吧。于是就有了下面这个class

public Class PropertyLoader{
   String[] files;

   public Map<String, Properties> loadProperties(){
      //....
      // for each files, read the properties files content and put them to the map 
      // return ..

   }

// setting injection the location of files
   public void setPropertyFileLocations(String[] files){
       ...
   }
  
 

}

 这段代码够简单的了，也很明了，PropertyLoader 有一个setter 可以inject所需要load的configuration file. 如果我们用spring 这可以extract到一个configuration file里面，最后的结果是我们有一个configuration property

filesToBeLoad=c:/config/config1.properties, c:/config/config2.properties,c:/config/config3.properties

在intial 测试中都没有什么问题，我们顶多也就是有3-4个file要去load。 developer觉得简单，customer也满意。结果一旦deploy, 问题来了，1. 经常有人拼错文件名, 2. 大小写敏感（windows working, linux not working)。 而且随着业务量的增加，要load的file超过了10个。

当这个class最初设计的时候，我提出过auto load, 也就是说你给我一个directory, 我去读file system。 但是写code得人认为他们应该simple design, 所以就没有这么做。

经过这个小故事，我们应当反省一下什么是简单，简单( The Simplest Thing That Could Possibly Work )决不仅仅是你的code要简单，而是从整体 上而言，包括配置，UI, 使用 都要简单。 为了追求code简单而去牺牲配置的简单是不可取的。我虽然少写了10行code, 而配置文件多了容易出错的1行， 都是要不得的，去remove那多余的一行configuration的cost 要比你当初多稍微的“复杂化”以下你的code的cost多很多。

• Windows7在微软WinHEC 2008上揭开神秘面纱
• 搜狐网站诚聘Java、PHP和C++工程师

自打XP提出pair programming来，在学术界也不乏讨论。 今天就让我们来研读两篇pair programming的学术论文。

[1]The Costs and Benefits of Pair Programming 发表于 2000年 Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering， 出自 agile的先驱者（个人认为是鼓吹者） alistair cockburn的笔下 该文得出7点pair programming的好处是

1. many mistakes get caught as they are being typed in rather than in QA test or in the field (continuous code reviews);
   
2.  the end defect content is statistically lower (continuous code reviews);
3.  the designs are better and code length shorter (ongoing brainstorming and pair relaying);
4. the team solves problems faster (pair relaying);
5. the people learn significantly more, about the system and about software development (lineof-
   sight learning);
6. the project ends up with multiple people understanding each piece of the system;
    the people learn to work together and talk more often together, giving better information
   flow and team dynamics;
7. people enjoy their work more.

同时对于时间的cost是 15% more 而不是预期的100% more.   但这15% 会在以后的QA和后期维护中抵销掉。

我比较在同1，5 ；   怀疑2，3， 4； 对6持保留态度，彻底反对7。

2,3 是要depend on 人的智商和经验的。4. 如果两个新手pair，或是一高一低，显然速度没有高手快。6，虽然正确，但是我持保留态度，一方面原因是job security，毕竟我们都是打工的，如果把developer都当作hot swapable的component，个人觉得太残酷了，一个process不能体现人性化的一面 （你随时可以走人哦，我们这回这东西的又不只你一个）的practice是不能让people enjoy的。当然信任都是相对的, 如果一个资本家认为layoff的成本是0， 你说他会怎么做。 另一方面为了lay off cost是0 去做到multiple people understanding each piece of the system本身就是一个high cost的事情。  

[2] Are Reviews an Alternative to Pair Programming 发表于 2004年的 Empirical Software Engineering 该文得出的结论是

1. A pair of developers does not produce more reliable code than a single developer whose code was reviewed.
2. Although pairs of developers tend to cost more than single developers equipped with reviews, the increased cost is too small to be seen in practice

我的几个挺 XP 的朋友看了该文, 觉得是胡扯，但是它们本身是没有try过 code review的。 不过这个结论似乎也算是皆大欢喜型的。 pair == solo+review。  我个人的经验就是pair有时候缺乏review, 有时候findbug, PMD这些工具对programming的帮助比pair的更大

[3]Effects of pair programming at the development team level: an experiment 发表于 2004年的 Empirical Software Engineering该文 研究了 productivity, defects, design quality, knowledge transfer and enjoyment of work 得出的结论是

Pair programming increased the development effort of the first tasks considerably compared to solo programming, but later the differences were small .

Due to this learning time the pair programming teams had worse overall project productivity .

Task complexity did not affect the effort differences between solo and pair programming .

The pair programming teams wrote code with fewer defects, but were less careful in system testing, and therefore delivered systems with more defects . They may have relied too much on the peer review taking place during programming.

Knowledge transfer seemed to be higher within the pair programming teams.

Finally, we also found weak support for higher enjoyment of work in the pair programming teams .

[4]Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise  发表于 2007 IEEE Transactions on Software Engineering 33(2):65-86 这篇文章对295个java professional做了一天的实验 最后得出的结论 do not support the hypotheses that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions. 同时为了正确地完成task，需要有84 percent increase in effort。

学术界对pair programming也是褒贬不一的，有时候不同的论文和试验模型可以得出完全不同的结论， 所以很难从某种绝对的角度上讲pair programming优越于solo programming。  Pair or not pair, 我看还是取决于个人，团队和项目吧，把pp当作救命稻草只会误人子弟。 从根本上人性化的解决developer所需才是硬道理，google在这一点上做得很不错。

• Windows7在微软WinHEC 2008上揭开神秘面纱
• 搜狐网站诚聘Java、PHP和C++工程师

onsite customer是关系到XP成败的一个重要practice, 客户现场办公，有问必答。但是有几个客户愿意这样做呢 （至少我至今还没有真正见过或是听说过我周围的xp team 有真正的onsite customer）？

于是很多XPteam (大部分xp team 也在用scrum) 找出一个“德高望重“的管理用户经验丰富的公司内部人事 和客户交流，简称proxy customer（有时也叫product owner，如果team在用scrum的话）。

这个proxy customer完完全全就是骗人的东西，至少大部分proxy customer都是一个摆设， 我见过不下下10各这种product owner 或者是proxy customer, 每个人都真的是个proxy！ 我们问他， 他打电话给customer （当然不是立即打）， 然后告诉我们。 如果customer 有问题， 找他， 他forward customer的email, 顶多加一句请求帮忙之类的话。

proxy customer完全就是一个XP自欺欺人的产物，很多时候问其东西 他们很会推唐，什么technical question呀，什么我现在还没有这方面的requirement呀，完全不能满足XP对 又问必答 的要求， 所以很多时候我们只能make assumption, 但是这种assumption有50%的错误概率。所以很多时候我们 meet了所有的commitment, 但是最后最终用户还是跳出来说少了功能。

与其要这个proxy, 还不如 要一个 online customer,  或是改变一下XP的planning game 自己搞一个onsite developer去做planning．　

一直很难理解为什么XP提出这么一个不现实的理想状态下的practice　还有这么多人吹捧。 很希望大家交流和最终用户打交道的新的。

• Windows7在微软WinHEC 2008上揭开神秘面纱
• 搜狐网站诚聘Java、PHP和C++工程师

常常看到论坛上有人讨论PP（Pair Programming）,但是大多是纸上谈兵，书上云的过多。真正谈感受的少。 我在一家做XP的公司做了4年了，从做service到做product, 总的来说pair programming给我带来的的忧大于喜，缺点大于有点。

总的来说PP有它的优点，很多researcher也发表了论文，记得比较清楚的一片就是一个大学里面对一个班的学生分组实验，结果用PP的那组效率比较高。 但这毕竟是research, 给我们的启示是PP在某种特定的情况下的结果:

1. Pair的人必须对等 （同班同学）

2. Pair的人必须全力以赴 (同学们，老师在做实验哦，不要走神！)

3. Pair的人必须对要解决的问题有相同（或相近）的认知

而上面的3点在现实公司里却大部分情况下不能成立。1就不用说了，2，举个例子，如果有一个人生病，或是惦记的其他的事则会screw up整天的进度。3，和1相关，人的水平不同，不可能像大学那样对一个东西的认知近似。

我个人的经验是10%的pair时间是高效的pair，其余的则是浪费时间 。

另外从人性的角度来讲，pair on everything则是对人性的强奸 ，强调沟通没有错误，但是工作毕竟是工作，如果天到晚说比写花的时间更多，则有点本末倒置了。我们公司是100% pair, 任何的task，不管有没有必要，都要pair （条件允许的话）, 老板的原则是绝不让任何一个知识点停留在一个人的脑瓜里：）,一个人躺下了，另一个就能补上。 但是从现实的角度来讲，我们的产品的确出现过超过一个developer走了，结果他们经常working的那个module就会没有人能够维护了，结果需要重写。 所以从knowlege spread的角度来说，公司的benifit和情感留人+document, 比pair来的更实惠。

另外pair的确剥夺了developer的个人空间 。 以前的公司， 上网灌水，给朋友 MSN, 的小动作全都不行了：（， 也许有人会说这些的东西在公司应该禁止！ 但是现实一点，我来java eye灌水 ， 跟几个圈内的朋友msn讨论心得，是对工作有正面影响的。 而且msn的圈内朋友对于疑难问题的帮助会很大的。

而且还有一点最大的就是pair剥夺了自学的时间 ， 没有pair的时候当有东西不会的时候， 对一个问题的研究会刨根结底，但是pair的时候，如果你的partner会，他大概只会给你概括一下，如果你的partner不会，那就会是一个非常有趣的pairing session, 什么google, yahoo, 大部分情况，结果是 this is a fking task that we should never touch as we dont have corrosponding knowlege... 但是如果一个人能够静下心来把问题的来龙去脉搞清楚，把相应的prerequiste的knowlege搞清楚， 问题在得到解决的同时，自己也会得到提高。说白了当两个新手在pair的时候的确很低效，而且不利于“成长”

说了这么多， 一句话

少Pair可以怡神，多pair的确伤身， 不pair也能过日子 。

• Windows7在微软WinHEC 2008上揭开神秘面纱
• 搜狐网站诚聘Java、PHP和C++工程师

• Windows7在微软WinHEC 2008上揭开神秘面纱
• 搜狐网站诚聘Java、PHP和C++工程师

• Windows7在微软WinHEC 2008上揭开神秘面纱
• 搜狐网站诚聘Java、PHP和C++工程师