结对编程——我的噩梦

标签: 结对编程 噩梦 | 发表时间:2016-04-16 05:55 | 作者:
分享到:
出处:http://kb.cnblogs.com/

   英文原文: Pair Programming - My Personal Nightmare

  自从 极限编程诞生起,我就一直在听说结对编程是个 好东西。所有的敏捷传教士们都在告诉我们:结对编程能提高代码质量,有助知识共享,甚至激发开发效率,同时,还能深度拉近程序员之间的感情关系(参看 拥抱编程)。

  那些拒绝结对编程的人都被认为是独行客,懒蛋,或社交恐惧症患者。然而,我不属于任何一种(至少我自己是这么想的),可我仍然讨厌结对编程。为什么我会这样?下面是理由。

  我们这个社会已经不再崇尚沉默是金,外向性格受青睐。所有的事情都要用合作的方式完成,每个人都要时刻准备好为他人服务,个人空间已不再存在,工作成绩不再归功于某个人。基本上,大家都认为三个臭皮匠胜过一个诸葛亮。

  然而,很显然,我们可以看到,有些事情并不是这样的。即使在编程界,很多伟大的创新和杰出的软件都不是由一个团队或某个组合创造的,而是来自一个人的努力。 Ant,给Java社区带来巨大飞跃的软件,就是由 一个人在从欧洲飞往美国的飞机上开发出来的。还有,一些更近些的例子, Notch 开发 Minecraft, Marco Arment 开发 Instapaper, Gabriel Weinberg 开发 DuckDuckGo,全是单枪匹马的成就。事实上,地球上最有影响力的一个编程大师, Steve Wozniak,有一句著名的教导:

“单干,拒绝团队,拒绝委员会。”

  视线放的更远些,很多科学界和艺术界伟大的思想家都是喜欢埋头工作的类型(内向性)——达尔文,爱因斯坦,牛顿,就连漫画家 Seuss博士也是这样。甚至诺贝尔文学奖的得主、《 愤怒的葡萄》的作者  John Steinbeck 也要在这事情上插嘴说:

两个人一起什么都干不成。合作永远是不成功的——无论是在音乐创作,艺术创作,诗歌创作,数学研究,还是哲学理论研究。只有在奇迹诞生之后,团体才去开发/扩展它们,但团体永远发明不了什么。伟大的思想往往生长于孤独的心里。

  好吧,我是有点高谈阔论哲学了,回到我们的小世界,软件开发,为什么我们要相信——如很多人极力主张的——极限合作(例如结对编程)是高质量代码或高工作效率的保障?却忽视如此多的现实反例?为什么——按某些人的说法——结对编程是“必须的”——在所有工作中?

  我认为这种观点只是个人的内心心理的外现。很简单:有些人喜欢这种形式的工作,所以他们会这样建议,不厌其烦的,让每个人都这样做。

  然而,真实情况是,我们 三分之一的人都是内向的(可能程序员中的比例会更大!)。总体上,我们人类不仅喜欢孤独的工作,而且在孤独中繁荣。并不是我们不喜欢其他人,而是我们的大脑神经会因此受到更多的干扰。对于我们程序员来说,高质量的工作来自于进入并保持一种“ 意识流状态(参看 一种境界)”中。能做到这些,我们就能高效率,否则就不能。

  Demarco 和 Lister 在他们著名的 Coding War Games 实验中验证了这些——他们发现,判断是否能够成为优秀程序员的最有效的先兆不是他们将有多少年的经验,而是他们工作的办公环境是否足够安静。

  以前人们是重视这种认识的。关于工作场所的  Joel on Software Test 这篇文章的第8点就是“程序员是否有安静的工作环境?”然而,很遗憾,极限协作的文化颠覆了我们大脑的工作方式,说实话,我认为这是让人痛恶的。

  结对编程,作为“everything-together”文化的延续,渗入到人们的思想中,以至于很多人认为一个人独自工作不仅低效率的,而且很无趣。而对于我来说,这正好相反。我的最佳工作状态就是与世隔绝,大脑流状态是我作为程序员最享受的事。并不是我喜欢做独行客,或我是圣人不会犯错。我十分倡导严格的代码审查,我每天都从别人的观点/指教中受益。我只是认为结对编程不能让我成为一个更好(更高兴)的程序员。我实话实说。

  当人们把结对编程描述成一种他们从中受益的编程方法时,这很好,我祝贺他们。但他们进一步鼓动(要求)我进行结对编程,说他们“知道”我将也会从中受益(而且还有“数据”证明!),打住。一个人能够高效编程的方法并不一定就会适合其他人。想一想这世界上很多伟大的成就(或就在你的项目中),显而易见。宣称适合外向人的结对编程对所有人都是“最佳方法”,这是愚蠢,我不屑这些敏捷教条主义者的言论。

相关 [结对编程 噩梦] 推荐:

结对编程——我的噩梦

- - 博客园_知识库
   英文原文: Pair Programming - My Personal Nightmare.   自从 极限编程诞生起,我就一直在听说结对编程是个 好东西. 所有的敏捷传教士们都在告诉我们:结对编程能提高代码质量,有助知识共享,甚至激发开发效率,同时,还能深度拉近程序员之间的感情关系(参看 拥抱编程).

InucurryFont,噩梦字体

- 季季 - 比特客栈的文艺复兴
为什么字体名称不是Incubator. 因为魔法少女小圆并不是Gekidan Inu Curry(劇団イヌカレー)第一次使用这种字体. 请见天元突破官方小剧场之オレノ×××ハウチュウヒトツ. 下载来源,本地下载,字体研究.

转:结对编程的误区

- - 膘叔
结对编程在我们现在的工作中真的没有使用这玩意. 极限编程也没有用到,我们还是安稳的在一步一步的开发. 其实,在07年的时候,那时候和一哥们就尝试过结对,效率确实上升了不少,但后来仔细想想,正由于两个人水平相近,这样的结对却没有真正带来了效率上升,反而还不如两个人单独开发,事后合并代码. 虽然有一些BUG,但总体代码却多写了很多.

敏捷结对编程实践

- - 技术改变世界 创新驱动中国 - 《程序员》官网
本文主要从提升项目质量、促进知识传递及减少项目风险等角度出发,讲述作者所在团队在结对编程实践中的一些经历,以及如何避免或减少其所带来的负面影响. 也许你还未曾尝试甚至还不曾了解,那么我们一起来学习和了解敏捷结对编程实践,相信对敏捷感兴趣的你会有收获. 结对编程(Pair Programming)是一种敏捷软件开发实践,指两个程序员并排坐在一台电脑前,面对同一个显示器,使用同一个键盘和鼠标一起工作.

噩梦背后的秘密

- JR - 译言-每日精品译文推荐
来源The deep meaning of nightmares.        噩梦,正如坠入地狱一样的恐怖,它的存在有意义吗. 没人能逃脱噩梦的魔爪,噩梦为我们敲醒了警钟,而不是带来了伤害. 我们不能忽视它们,更不能不回忆所做过的噩梦. 噩梦是痛苦的,但同时也是必须的治疗药品. 通过这样的情感发泄,它们可以起到很重要的治愈作用,同时警告我们不曾留意的心理失衡状态.

结对编程的价值及注意点

- - Juven Xu
结对编程( Pair Programming)可能是最受争议一项的敏捷实践,持续集成和重构基本已经普遍被大家认同了,TDD还能引发 很大的口水仗,倡导结对编程则有被狂砸砖头的风险,本文我不想说结对编程绝对有多好,我想分享的是一些有关结对编程我体验和观察到的价值,以及几个我认为特别需要注意的地方,尤其是后者, 如果以错误地方式用结对编程,弊很可能大于利.

结对编程成为主流,但反响冷淡

- - InfoQ cn
华尔街日报开始注意到越来越多的技术公司在实践结对编程,并在题为“ 计算机程序员在共享中学到深刻教训”的文章中发表了自己的看法. 在技术公司中,结对寻找到了支持者. 这些公司包括Facebook和移动支付创业公司Square. 结对的倡导者对结对的力量赞不绝口,声称结对程序员可以捕获不采用结对时需要花很大代价才能找到的软件错误,而且不太可能花时间上网冲浪.

变化是如何产生的——有关结对编程

- - Juven Xu
一个十多人的团队,十个月前,每个人都习惯在自己的一块自留地代码上劳作,当管理层推结对编程时,大部分人反应冷漠甚至抵触. 今天,这个团队的几乎所有人都愿意接受结对编程这种工作方式,各个人对整个系统的了解更好了,遇到不熟悉的地方都很自然地想到找个熟悉的人来结对,很自然的,团队合作更好了. 然而,同样的公司,不是所有的团队都有这样的变化, 自留地式的工作方式在一些团队非常普遍,这是为什么.

结对编程 VS 代码审查:对比开发者文化

- - ITeye资讯频道
从上一份工作到现在的这份工作,我从结对编程的开发文化过渡到同行代码审查,这个转变过程是一个非常有趣的经历. 我认为我要记录下些我所注意到的变化. 你可以找到很多标题是/(结对编程|代码审查)的(利|弊)/这种样式的文章,这些文章的作者都可以给出一套清晰且有说服力执行方案. 我认为只要权衡它们的利弊,这两种方案都是非常有效率的.

[笑话连篇] 央行加息 银行柜员的噩梦 噩梦!!!! (转载)

- liangzi9 - 水木社区 今日十大热门话题
发信人: xyhou (逍遥侯), 信区: Joke. 标 题: 央行加息 银行柜员的噩梦 噩梦. 发信站: 水木社区 (Wed Apr 6 10:26:10 2011), 站内. 【 以下文字转载自 MyWallet 讨论区 】. 发信人: JJxDD (~反指悲催不卖不涨不空不跌帝~), 信区: MyWallet.