初尝结对编程的甜头

本文作者：sodme
本文出处：http://blog.csdn.net/sodme
声明：本文可以不经作者同意任意转载、复制、引用。但任何对本文的引用，均须注明本文的作者、出处以及本行声明信息。

　　这一两个星期，一直在跟客户端作代码整合和调试的事。在跟客户端联调之前，服务器端我已经自己写了一个模拟客户端与我自己的服务器进行逻辑测试，在数据包的处理流程上基本已经跑通。所以，剩下的活就是跟客户端的人员一起联调他们的逻辑和代码。

　　联调的方式，形式上有点象结对编程，我是那个坐着旁边“只说不作”的人，真正写代码的仍然是客户端的人员，我主要负责帮客户端人员理清他们的逻辑和思路，对现有的架构和代码提出修改建议，同时“监督”客户端人员的编码过程，帮助其及时纠正由于思维“盲角”导致的小错误。这一两个星期下来，感觉颇好，同事之间的合作既轻松也愉快，在效率上感觉要明显比以前更快了。

　　在XP编程的相互协作中，有几点感触想说出来：
　　1. 不管是说的那个人，还是作的那个人，两者都得要习惯这种编程方式，虽然从形式上看是两个人用一台电脑在写程序可能会造成公司的人力资源成本耗费，但从产品质量和工作效率上来看，这样子写出来的代码在安全性和易维护性上都要比一个人写的要强得多。公司的开发成本，并不会因此而大大增加，相反，而是减少。有条件的项目组，可以试试。

　　2. 结对编程，不一定是贯穿于项目始终的，或许，我们只是在项目进展到某一个阶段时，而临时采用了结对编程的方式。比如我所遇到的这种客户端与服务器端的代码整合工作，这项工作是很繁琐的，客户端人员和服务器端人员必须通过充分的交流和沟通，才能在数据包的执行逻辑上达成广泛的一致，从而在游戏逻辑上实现默契的相互配合。在这种整合工作中，要绝对避免服务器端的人员写好自己的代码后，对客户端的编码情况不管不问的情况出现，不管是基于团队合作的需要，还是基于项目的正常进展，任何一方在完成手头已有任务的情况下，都要积极介入另一方的开发为队友提供帮助。好的团队，不是天生就有的，是靠每一个团队成员，用“心”去培养的。

　　3. 平等交流的原则。作为有时间积极思考的一方“坐在旁边的那个人”，由于他并不担负具体的编码工作，所以他的思路可能相对于实施具体编码的那个人要更为清晰一些，看的层面也要更深、更广一些。当你的设计思路与编码人员有冲突时，要本着互相尊重的原则平等交流，把你的设计思路尽可能地解释清楚，尽可能客观地分析彼此设计方案的优缺点，作出正常的评估。不要在思想上先入为主，片面否定对方，胸襟要开阔。

　　4. 知错便改的良好修养。作为实施编码的人员，从劳动量上来看，或许你的劳动量要比只说不作的那个人劳动量更大一点，或许你会时不时的抱怨对方提出的方案是“说起来轻巧，作起来难”，但只要对方说的是合理的，就要尽可能地去完善和修正，将来有一天你手头上的事比较少时，你也同样可以参与对方那个模块的结对编程，那时你也可以作一个“只说不作的人”，所以，不必心理不平衡。^&^　当对方对你的设计方案提出质疑时，你要客观地想一想对方说得对不对，出于本能，你可能总是试图说服对方自己的方案是对的，尽管你心里可能已经在悄悄否定自己的设计方案了。如果你的内心有这种倾向，强烈建议你不要再死撑了，你应该及时纠正自己的缺点，将方案变得更完善和合理。有错本身，并不是什么大不了的，关键的是，知错要改。最重要的是，同样的错误，不要屡错屡犯。

　　5. 设计风格是各人自己的事，不必强求。也许很多公司都有自己的所谓的编码规范，但写代码的老鸟，基本上都会沿袭自己长久以来的编码习惯，很少有人专门为了迎合公司的编码规范而刻意去写。只要代码是易读的，结构是清晰的，逻辑是正确的，我觉得各种设计风格是大家每个人自己的事，不必去强求。如果在这一点上都一定要钉是钉，铆是铆的话，可能会让彼此都郁闷得很。因为，你不能说哪种风格就是错的，最多，你只能说哪种风格是更为易读的和易维护的。结对编程的双方，在编码风格上，如果比较相近更好，如果相差比较大，那要看是不是满足我上面说的三点“代码是易读的，结构是清晰的，逻辑是正确的”，如果满足，就各安天命，你走你的阳光道，我过我的独木桥，你不必强求我，我也不必强求于你。

　　总而言之，结对编程，在水平相差不是太大的二者之间进行实施的话，工作起来我觉得还是很快乐的，呵呵。愿大家每个人每天都能以快乐的心情写代码！