[技术讨论]交换编程实践与延续

 

相关文章

如果要了解交换编程，可以先看看下面的几篇关联文章，这样才能更有助于理解本文中的一些内容：

[技术讨论]结对编程与交换编程的对话：http://blog.csdn.net/qingrun/archive/2006/12/07/1433588.aspx

交换编程csdn官方blog发布了网络版本：http://blog.csdn.net/programmer_editor/archive/2006/12/07/1433092.aspx

[技术讨论]关于结对编程实践的一段对话：http://blog.csdn.net/qingrun/archive/2006/12/10/1437443.aspx

[团队管理]结对编程引出的话题——企业管理与程序员规划的对话（修改总结稿）：http://blog.csdn.net/qingrun/archive/2006/12/12/1440190.aspx

[技术讨论]关于交换编程实践的交换周期问题 ：http://blog.csdn.net/qingrun/archive/2006/12/20/1450091.aspx

老兄弟老问题

昨天在成都见到了以前一起工作的弟兄，他现在还在原来的单位工作，还在做原来的项目，我听说了原来那个公司的最新情况，感觉：他们终于熬出来了。

期间，他就提到他们目前有一个问题，每个人负责一个大的模块从头到尾，结果每个人的模块自成体系，在检查错误与测试的时候遇到了很多问题，主要是因为每个人的自查起不到效果，同时由于每个人做自己的模块都已经有四年之久了，这样的结果使得每个人都对自己开发的代码有相当高的认可程度，因此在进行新版本开发的时候，就很难进行调整和人员间的协调，当然还有因此产生的一些关联问题。

这个项目的背景在交换编程那篇文章中作过简单的介绍，目前这个项目已经进入了第四期，可是同样这个第四期，还是处在MIS系统阶段，始终没有突破我04年那篇规划中提到的第二阶段：专家系统。

由于最高领导有了变更，所以，我甚至有了想帮助他们完成这个项目后续进展的考虑，当然，这个考虑目前对我来说，还只是一厢情愿。

好了，废话少说，我继续前面的问题。

当听到这里，我就问他，是否还记得当年做完需求后，我给大家提到的要求进行轮流交换开发的事情，他说他有印象，但是，不明白为什么。

于是，我给他讲了一下交换编程这样做的好处，这样做，正好可以解决他们目前遇到的那个问题。

其他朋友的疑问

说道这里应该提一下另外有一个朋友的疑问（这个朋友的疑问是写在程序员杂志blog上的内容，我在这里做一个回复）：

“

关于交换编程，我也考虑过很多，在很久以前想想结对编程的时候，就考虑过，感觉上交换编程有一些问题不好解决： 1：每个人都要理解上一个人的思想，思路，这样的时间应该是比较耗费的， 2：每个人都有一定的思维惯式，交换的时候，缺少一个人在身边，这样很有可能这个人把上一个人的思维更改成自己的思维模式（比如文档，代码），这样很有可能给后面的人和原作者带来一定的困扰。 3：接手的人，是否会为上一人擦屁股，如果上一个人写的比较差的话，那么接手之后，如果接手得人没有责任心的话，那么可能就会让差的代码越发的差，这样可能发生代码腐烂的问题。我觉得人总是受环境的影响比较大，特别是一些没有特殊洁癖得人，比如一段代码写了注释，那么后来得人，可能接着写，如果前面的人就马马虎虎，凑合的话，那么后面的人会更凑合，就像Tom Demarco的那本《程序员修炼之道》中说得救火队员去救火的那个故事一样，如果屋子干净的话，队员都要扑上垫子，才敢进去救火。 当然了，如果上面的全部反过来的话，这个就是一个比较好的实践了：）

”

这里我一个一个回答：

1、关于理解前一个人思路的问题，这里应该根据工程项目情况和团队组织以及人员变动情况进行综合考虑，如果一个人在公司的时候，你都无法理解这个人的思路，那么当这个人因为某种原因离开公司后，你还能让原来的模块继续下去么？

这里一个潜在的问题就在于这个公司这个团队在项目开发过程中是否有一个整体的规划和考虑，如果完全是一盘散沙的合作，那么，交换编程也比单人编程更有优势，毕竟，你进行交换的时候，大家都还在公司内，如果离开了，岂不是更是断层了？

这个时间的耗费是否值得，我相信每个人都能衡量得出来。而另一方面考虑，如果一个人所写的东西无法被第二个人所理解，那么这个人的工作，岂不是没有任何价值了？那你要这个人来做事，明摆着是把自己放在了即将喷发的火山口上！

2、这个问题同样也是交接的问题，另外就是整个团队是否具有整体性，大家做的东西是各自为战，还是有一个相对统一的规划考虑。最基本的规划考虑是必然要存在的，否则，这个团队也就不是团队，这个项目也不可能成功。

另外，每一个人给第二个人讲解自己想法的时候，其实也是主动地对自己的开发过程和思路进行了一次完整的review（重新评价），讲得过程中就会让他自己想到一些自己没有考虑成熟的电荷一些还有疑虑的问题，通过这种交流，就可以将这些问题扩大化，摆出来，让所有的人都看到，这样才能及时地解决，否则，这些问题就会隐藏起来，直到项目结束的时候再被发现，那时候，就不是坐在火山口上了，而是直接调进了熔岩里。

3、这个问题我个人认为，是不需要讨论的。因为如果经过这样的交接，项目领导者也会发现第一个人是否是在做事情，是否称职，如果说第二个人就是在给第一个人擦屁股，那么，第一个人是否应该存在在这个团队中，他存在是否有价值，这就是管理者应该考虑的直接问题。

同样，这种擦屁股，也会把隐藏起来的未知的问题显性化，让大家都看到每一个人所做的事情的价值，对于评定程序员的工作量和工作质量无疑是有好处的，而且具有现实意义（现实意义就是说不是单纯的指导意义，而是可以直接付诸实施的措施）。

我相信经过上面的解释，应该可以说明交换编程的作用了，这其实也是把同行评审工作直接放入到开发过程中来进行，将那些可能流于形式的同行评审变成了现实中的开发实践。