新手到底新在什么地方

个人感觉让老手和新手进行pair是会产生问题，我在想是不是gigix和gurudk间'新手'的定义发生了冲突，你知道的，gigix所在的TW就算是新手也都是不简单的，只是刚进公司而已，其实是拥有一定编程基础和经验，而gurudk所定义的新手，我想可能指大学毕业，拿着2000不到的工资，还没有任何实际编程应验的小P孩，这一点首先需要分辨清楚。

其次针对小P孩，我的看法是这样的:
在一开始，你不要对他们有任何期望，这是最重要的，你不要把他们想成和你一样能够独立成长，他们需要你和你的团队来带，需要一个过程。

几点建议:
1. 所有他们写的代码都需要由专人做Code Review由专人讲解代码中的问题。这里结对的效果可能会更好些。
2. 多做讲课，将一些重要的问题拉出来单独讲解。
3. 多教教他们解决问题的能力。我们很多’老手’都对新人十分不满，经常说’这点问题都搞不定’之类的，你们有耐心告诉过他们该怎么看书，该怎么分析问题吗?

大公司，就像TW直接招熟手能人就可以了，小公司，就老老实实的带人，从大学生带起，虽然很多人都是在帮别人培养，但一定要坚持不懈的做下去，直到变成像TW这样大公司为止。

最后说一句，让老手和新手结对绝对是BT,一个人永远写另一个人永远看，一个人永远正确另一人永远不正确，如果新手碰到任何一个问题都需要让老手讲解一下，这个代码是写不下去的。Pair只存在于两个水平接近的人之间，不知道这样的理解对不对。

LS说的比较实际：

 

 

结对编程给我感觉还是有点阳春白雪，我认为关键还是提高质量的意识，只要让新手明白做项目不是做课设，我想问题会简化很多

我们每年都招应届毕业生
而且不管是怎样的“新手”，反正你也得培养他。你不跟他pair那你怎么弄呢？把他当蘑菇搁角落里晾着？还是随便扔个东西给他等他做完了你再帮他擦屁股？别骗自己了，反正你要付出大把时间和精力培养他的，干嘛不跟他pair呢？最不济了，让他坐在你旁边看着你编程，你一边写一边给他讲，就算他不能全听懂至少比他自学来得快吧，至少他学习过程中不给你带来负的生产率啊。

其实，不对。一个人永远写一个人永远看，这种情况也有。发生在什么时候呢？就是我前面说的，你的目标就是不让新手带来负的生产率。换句话说你在赶进度，让新手坐旁边学着，学多学少无所谓。这种时候你是无论如何也没办法带新手的。你还不能让他自己干活，因为你还得给他擦屁股。
但是如果你不是特别赶进度，你有时间和精力带新手，那么你完全可以让新手来编程。pair programming有一种模式叫做ping pong，老手写一段测试，说我要做什么什么，新手写实现，让测试通过。这是一个很有效的带新手上路的办法。另一种模式（我忘记叫什么名字了）是更直白的coach，老手拿鼠标新手拿键盘，老手把鼠标指到需要做事的地方，说现在我们要做什么，新手来做。
结对不是说俩人坐在一起就有效了，这也有很多模式和经验的。

呵呵，明白gigix的意思。
其实pair是有很多技巧和方法的，不过换句话说，很多小公司小团队的负责人本身管理经验不足，很难摆平一些事情，在没有任何理论上，经验上的大力支持是很难将pair实施下去的。

其实我倒是觉得pair是一种很好的监督机制，监督你不能乱上论坛，监督你不能乱聊天，pair机制本身一定程度上和员工的'自由'存在一定的利益冲突。还有一个冲突存在在性格上，有时候碰上2个话多的，或是2个闷罐都够受的。

还有老手一直在带新手会觉得很累，至少我是这样想的，心理上的压力吧，而带出来以后又不能帮自己干活，艾。

所以说在没有任何基础，没有前提的情况下，要靠摸索形成一套pair机制，悬。

你是boss?

Pair只存在于两个水平接近的人之间!
支持此观点。

关键在时间估算时并不是当新手来估算。有几个公司把生产率是-0.5估算的。如果这样老板就要开人了。

是啊！工作了做真实的项目可不像是在学校里面交作业了...

团队的软件质量标准往往、也应该比客户的质量标准高，这样可以大大增加客户满意度。新手，往往只是满足有功能，而不追求质量。

 

同意，呵呵，长期以往，就算是做边角料也要做得完美。

大哥们带头，不对的地方要指正，而且双方都要诚恳，要提示新手几下提得意见。