关于pair coding

先排除一下歧义， 我上边的coding就是programming的意思。怪我用词不准

可是，从你的帖子中，我觉得你说的 coding  就是coding的意思啊。

另外，我前面的帖子中的红色引用，我觉得是不正常的政策和方法所导致的。

程序员与代码工的区别
程序员会把工作量下降下降再下降.降到最小
代码工,把设计,转码成源代码.

你们公司大多数人是程序员,还是代码工?

pair的关键还是看pair的人互相之间是否可以配合默契，两个pair的人在技术上一定要比较接近的才行。配合好就没问题

我猜会不会跟做人有关，如果大家都真心为team着想，为项目着想，只要找到一个平衡，那么事情就好办了

头一次听说，真搞笑，哈哈哈！

--------------
没价值? 难道你交付给客户的是需求,是文档,是代码走查报告?
你就忽悠吧. 总能见到说看不起编码工作的一类人代码写得丑陋之极.

--------------
Pair的实践并不是单独存在的，还有其它best practice与其配合, 才会产生一个整体的效果

你软件的时间大多数用在哪里?
如果有一半时间用来coding的话算我没说.

不管怎样我觉得老抛这次的话还是很中肯的。

站的角度不同的关系，明显老抛是在从程序员的角度上考虑，为程序员着想。coding的比重要小一些。最初的设计决定最终的代码实现，如果coding更重要岂不本末倒置！只是看那条路更适合年龄越来越大的程序员。

你是站在公司老总的角度上看问题的，作为公司老总着想的。恨不得连文档说明都没有，是为了节约公司成本（包括程序员），连代码都不用，直接交war包什么的得了。

对日外包还是看侧重点吧。对于文档，管理，review，test，coding的流程确实比较严格。学60-70%就好了。之后看自己的侧重点。就算是大公司，水平良莠不齐能急死人。可以想想一下那些毕业之后就进日企干3~5年的，有的think in java都没看过，review代码的时候逻辑是日本人的，剩下的代码结构就是自己的“创造”了。时间久也是一塌糊涂。所幸在那里接触了2个以前没有接触过的框架和一些流程什么的。干了3年，刚刚起步的新手说。

本人毕业前都是自己独立做网站，做了一年多

后来去一家公司实习，带了几个只是在学校里学会了点C的人开发一个网站，做了半年多

毕业后，离开实习的公司，一直到现在，一年半的时间里，都是在结对编程

技术总监是个技术牛人，近二十年的编程经验，一直与国外的一些技术精英有着交流，他非常推崇极限编程，公司也一直在采用结对编程。

他始终认为，结对编程的话，一些像NullPointer之类的基本bug是不可能会出现的，除非是一个人偷懒，结对编程能尽可能多的节省调试bug的时间，因而能大大提高开发效率，并且从带新人方面，能快速地使新的员工的技术水平得到提升，并且能使更多的人熟悉系统，从而可以防止因为某个员工的变动而出现断层。这些大多都是极限编程所表述的内容。

但从这一年多的开发中，我有以下的一些看法

首先是优点。
1）假如结对编程中并且都是善谈的人，结对编程的效果可以较好地呈现，大家都互相地分享经验，可以更好更快地让新员工提升自己的能力，这都是有目共睹的

2）假如结对编程的两个人都可以保持高度的精神集中，开发中将能大大地发现一些错误，从而将这些错误在开发的阶段就可以fix，避免了无谓的debug

3）假如在结对编程中，两个人都始终保证对系统的熟悉，那么其中一个员工发生变动，对系统的影响将可以减少至最少

4）假如员工都有差无私奉献的态度，那么团队互相之前的经验分享将变得非常和谐，大家都能学习到其它人所发现的新鲜的玩意

5）假如结对编程的两人水平差不多，那么互相提意见，将会大大地扩展两人的视野，另一人总会表达自己的一看法与建议

6）其它假如这里就不一一列举了

然后就是缺点
1）假如结对编程中两个都不是健谈的人，或者说一新一老员工时，老的员工不健谈，那么自始至终，就会有一人始终保持着被动，看着另一个人不断地拉动滑动杆，切换代码，很快，这个人就必须得靠咖啡以保持自己的眼睛不闭上了，如果你说他不善谈的话，请来干嘛，问题是，事实上公司不可能保证每个请来的人都是非常善谈的，假如还要以假如作为保证，那么效果也只能假设了，见过很多的例子就是，一个较熟悉系统的人，带着一个新人，结果新人跟了他几个月，结果系统一点也说不上了解，反而连一些最基本的代码也写不出来

2）假如结对编程的Navigator不能保持精神集中，那么他的作用就基本会降至非常低的水平，即他会白白地拿工资，而不用干活了，代码始终变成一个人写，另一个人白看，一个人干两个人的活，手累，心更累，怎么能保证每个人在每天都保持高度的集中，这是不可能的事，等程序出了低级错误，再去追究当时的Navigator的错误？这就等于对结对人两个进行挑拨

3）假如在结对编程中，一个熟悉系统的老员工带着一个新的员工，在过了一段时间后，老员工因为某些原因缺阵，新员工仍然需要很多的一段时间，才能熟悉系统，因为他们从老员工学到的，只是在这段时间里，一起做过的一部份代码，如果他们在一起的时候一直在做bug fix，那么这个新员工所接触到的部份就可以说可以不必提了

4）假如员工都那么无私，这个假设成立的几率太低了，结对编程中，一个人的自私，将会引起另一个人的自私，分享将成为障碍，一起坐在一台电脑前，缺有着暗斗争，这样真累

5）假如结对编程的两人水平差不多，在结对编程一段时间后，差距就会被慢慢拉开，于是一个人都会成为主导，另一个人由于慢慢地插不上嘴，会变得越来越没自信，慢慢地主导的人就会抱怨同伴不帮自己解决问题，变成一个人编写代码，一个人养两个人，累，于是主导的人不得不想怎么去偷懒

当然还有更多的点可以说，这里就不详提了，相信做过结对编程的人都会有深刻的休验


据我所知，结对编程，最初只是以学校的学生进行了实验，而得出的原型，在实践中，缺陷还是太多太多，不能盲目一味推崇

总而言之，个人认为，在适合的时候进行结对编程，效果非常好，就比如本人现在带着几个新人，首先pair几天，然后分享一些任务让他们独立去完成，然后隔一段时间去询问进度，如果发现他们有不能解决的问题，再短暂pair一会，帮他们解决问题，分析原因给他们听，这样自己就可以将一些琐碎的东西，当成给他们的练习题，自己则可以专注于框架方面研究，他们也可以在自己的思考中快速进步。但如果盲目跟从，全盘肯定结对编程，这样不但起不到应有的效果，而且会大大打击员工的积极性