|
|
国内为何很少有人做结对编程呢？是确实不好还是属于中国特色？
关注者
327
被浏览
136,563
37 个回答
匿名用户
CEO：那个A和B最近走的很近，每天上班在一起很大声不知道说些什么，你要提醒下，对别的部门影响不好。
技术总监：那个是我们正在采用的结对编程的实验，可以大幅提高工作效率的。
CEO：哦，反正你注意点，不要出乱子。
CEO：这个么简单个项目为什么要两个人去做，你不是说这个很简单么？
技术总监：不是的，我们现在在做敏捷，所有的项目都两个人一起做，这样效率高。
CEO：那个敏捷我不太懂哦，但是这么简单个项目要两个人一起搞，我觉得有点问题，你重新安排下。
技术总监边擦汗边说：好的，我们一定重新安排。
测试：这个项目谁做的？
A：我
B：我
测试：这个项目谁负责？
A：我
B：我
CEO：那个谁（技术总监），你来我办公室一下。
结对编程虽然只是一种形式，但是本质还是敏捷的文化，敏捷，是整个公司的文化，中国的公司只有两种文化：
散养文化，每天早上打鸡血，大家相亲相爱一家人。
圈养文化，每天早上不管有没有事先开一个小时会，所有事情流程制度化。
恰恰没有敏捷的文化，没有敏捷的土壤。
App Annie有开展结对编程，并进行过多次回顾，目前大家比较认可的看法是：
1. 结对编程特别适合于知识的分享和传递。特别适合于帮助开发者快速熟悉自己所不熟悉的领域。对于新员工，效果特别明显。
2. 如果两个人水平相似，并且对正在工作的领域都很了解的人，结对编程有浪费时间的嫌疑。但我对于这个前提是存疑的。除非特别简单的部分，很难有人真正能说对一个领域全面了解。
3. 结对编程很累。要求结对的双方都要保证有充沛的精力。
4. 结对的双方如果脾气对味，技术观点相近，结对会很愉快，而且碰撞出很多火花，效率有明显提高。反之，就可能陷入很多的争吵，而导致进度停滞不前。甚至影响团队协作。
5. 不是所有的工作都适合结对。技术验证和架构设计都不适合结对。结对比较适合在需求和架构设计明确后的实现阶段。常见的方式有一个人写，一个人看；或者一个人写实现，一个人写测试。一段时间后交换。
6. 结对编程不能替代代码评审。虽然结对编程对代码的审核程度比代码评审细致的多。但两个结对的人有明显的思维趋同性，从而忽略同样的问题或者犯下同样的错误。