眼睛一睁一闭，一天就过去了，嚎~~~~

嗯呐，一不小心，就又是好几天没更新blog。时间真的过的太快了。今天开了一上午的会，大伙聊了很多东西，搞的人比较high，这会离下班还有半个小时。任务也提前完成了。所以拿来写篇BLOG吧。

今天呢，就是同事给我们讲了一些Pair Programing的一些东西，算是Agile的一部分吧。当然，像我这种一贯喜欢否定的人总还是会提出很多自己的看法，毕竟，独立的思想与完整的人格我觉得是必须坚持滴。哇咔咔

好吧，不自夸了。今天要说的三点究竟是哪三点呢。请看大屏幕下面继续。

一，Pair Programing不一定就提高生产效率以及代码质量。记得我第一次看完《人月神话》之后，就坚信了一个观点：没有银弹。任何方法论或者所谓的最佳实践都有其自身的局限性，所以你要是给我说一个东西怎么都好，我直接心里就否定了。没有怎么都好的东西，包括现在这么hot，甚至都快过气的Agile这个big buzz word，当然也就有PP这个子集了。因为想起这些我就想起了CMM在很多年前的样子。诚然，Agile是有很多不错的理念，但千万要记得，没有银弹。PP也不可能面面俱到的。比如，性格不合的两个人去PP，互相谁也说服不了谁，结果一个变量的命名究竟是叫love_you还是LoveYou就争执了一上午，导致啥都没干。我主观不认为这会提高任何效率与质量。同样，俩人如果关系特好，互相默契很高，但如果很不专业，在一块躲在角落里偷偷的看《Prison Break》，然后每个小时看一集，再用剩下的不到20分钟时间里随便堆砌点垃圾去提交。这也是敷衍了事滴。再比如，如果你的上级给你们小组4个人每个人分了30个ticket。要求2天做完。这种根本是Mission Impossible的事情。你说这4个人会有心情PP么，会有心情考虑如何帮对方把代码写的优雅，把逻辑写的清楚不？反正我不信。还有，如果说我今天只不过是要修改一些页面上的typo或者是小样式，如果叫个人跟我Pair，他80%的时间里肯定觉得非常无聊。你觉得呢？上面举了好几坨例，有时候两个人会把事情搞的更糟，有的时候虽然不会搞的更糟，但是也会造成效率的浪费。想想Yahoo的衰败以及SINA的收购，过分的民主或者过分的股权分散，其实都是很不好的事情，会浪费很多机会，也会浪费很多时间去扯皮。在PP这里呢，就是PP不能确保提高效率以及质量。

二，一切方法论，包括Pair Programing其实最重要的因素都是人。嗯，确实是这样，从我上面举的例子应该看出来基本都是人造成的PP好用或不好用。其实这基本等于废话，计算机来说1+1等于2那就是定了。人喝多了那他可什么答案都敢说。人本身充满着不确定性，所以，把一切问题都归结到人肯定是放之四海而皆准的废话。可我还是喜欢强调这个，就是因为我发现虽然大家都知道人是问题的根源，但大家却不一定能重视这个认知。我把这个现象叫做‘认知回避’，是啊，谁没事愿意觉得自己这个物种是很不完善的呢。需要改进的呢。但回避也没用，反而后果更大。早点正视这个问题，正视你我包括所有人都有优缺点，都有不完善的地方，都会犯错误这个神一般存在滴事实，是很有益处的。只有你清楚的知道你的优缺点，你才知道如何去改掉缺点，或者如何避免你的缺点所造成的负面影响。好吧，说远了，回到PP，PP其实好处也是一大堆呢，具体的就google吧。可是如果想使PP发挥到如同那些大牛所说的魔力或威力的话，有一个很重要的条件，就是实施PP的人（之所以不说是第一重要的条件是因为第一条件肯定是得有台电脑-_-###）。你想想大牛说的那些魔力威力来自于PP，其实很大一部分也来自于那些人本身。因为他们本身就足够优秀，所以如果配上合适，科学的方法的话。那肯定做出来的成绩就更加的优秀了。所以，你如果想用PP也能收到同样的效果，那有很重要的一点就是除了按照大牛告诉你的最佳实践来实施PP本身，还一定要努力让自己向大牛看齐。包括你的人品，素质，性格，看待问题的角度，理解能力，沟通能力等等。这就好比乘法：PP比如说是5，如果你是2，那么得到的结果就是10，如果你是-2，那么得到的结果就是-10了。现在想明白了吧，PP重要的其实是你自身，流程啊，方法论，书上的探讨了，但是大部分PP的资料都不会讲关于提高你自身的方法，所以，速度补上这块短板吧。不然即便PP再好，你是个-2，那也没辙。

三，客观点，科学点。嗯，今天其实听同事讲PP这个topic，真的是听起来很美，但是最让我感到忐忑的就是没有数据。虽然developers都积极的表明PP提高了很多代码质量，可是从QA的角度就是还没有个数据。我觉得其实数据很重要。否则，空对空，很容易使大伙回到几十年前“赶英超美”那个疯狂的年代。所以，务实点，尽量脱离主观感觉，通过客观的数据来证明一件事物的属性，或者一件事情的好坏，或者一套方法论的可用性。这才是科学的态度啊。所以，我在会上也提了，希望可以量化PP带来的好处。看看PP对于我们的实际帮助到底是怎样的？不能莽撞认为我实施了PP，那PP资料里面所描述的那些个好处，我自然就得到了（想象曾经的EJB，真正让你得到了多少好处呢？）。科学的态度不是这样的，因为不要忘记了，想要发挥PP最大威力，你还得是那个2才行。（参见第二点）。

嗯，一不小心，就说了这么长，其实挺恨自个的，老喜欢跟人抬杠。但是吧，我爱科学啊。科学家最喜欢干的事儿就是怀疑与否定了。所以，对于这些看起来都很美的东西，一定不能让自己一下子就被带进去。不管是SOA, Agile还是最近的REST和SNS。因为真理往往掌握在少数人手里，也许你能多独立思考那么一晚上，你可能就能领悟到比别人更多的东西。同时也能训练着自个变得更加的客观。何乐而不为啊。

咳，老是一不小心就又扯的没边儿。好吧，准备就此搁笔吧。关于PP，其实我并没有深仇大恨，只不过赞扬的人太多了，我就想客观的说点别人没说或者没想的东西。

其实经历过这5，6年的软件开发，真的慢慢感觉出来一个道理：

成功的因素存在太多偶然性，而失败的因素中，很多原因确是具有必然性的，所以关注失败也许是为了迈向成功更好的一种途径。

所以，我现在很喜欢研究失败，研究最差实践，嗯，基本大伙管这个叫-教训。我想也许以后我会多聊聊关于失败，关于错误的事情？哈哈，看我时间吧。

PS：下一篇，准备简单聊下我对项目中各色各样的文档的看法。欢迎拍砖。