《构建之法》读书笔记第四章——结对编程

本章节讲的是结对编程和结对编程应当注意的地方，结对编程也是软工经典《人月神话》最推崇的编程方式之一，最早的结对编程记录是：

1987年，Intuit公司（当时只是一个刚刚起步的个人财务管理软件公司）宣布4月会向客户提供新版本的软件（4月15日是美国报税的截止日期）。但到了3月末，公司仅有的两个技术人员发现进度还是大大落后于预期，于是这两人在3月的最后一周开展了不得已的、长达60个小时的结对编程活动

这段经历在《人月神话》中也有记载。结对编程有以下好处：

1. 结对和单独开发相比，能保持一定的压力，鼓励双方保持代码的高质量

2. 改善代码质量，增加代码的可读性和可礼节性

3. 提高编程效率，往往能更快的编写代码，并导致代码的错误更少。

但是结对编程毕竟属于两人合作范畴的，如果两人编程习惯迥异，在一起工作中说不定会产生不小的麻烦。

此外，对于程序猿而言，代码时写给机器看到还是给人看的呢？

人也看，机器也看，但是最终是人在看。

书中这样说道。毕竟是给人看的，因此写代码的一定要注意代码规范，而代码规范分文两个部分：

1. 代码风格规范

   代码风格的原则是：简明，易读，无歧义。其中变量名和注释是需要特别的地方。注释应只用ASCII字符，如果用中文字符做注释，在迁移时很有可能因为解码方式的不同造成中文字符变成乱码。

2. 代码设计规范

   除了书写格式问题外，还应注意程序设计和模块之间的关系，其中最需要注意的是函数

   只做一件事，并且要做好

写好代码以后，不能忘记的还有代码复审。代码复审的目的是在项目早期发现其中的错误，并且能达到交流、互相教育学习、传授经验的目的。

做好一个事情最好能有反馈，无论是正面还是反面的，而代码复审就是写代码过程中的一个重要反馈来源之一。而结对编程能做到时刻代码复审，一般来说结对编程有两个角色：驾驶员和领航员，一个负责编写代码，一个负责监督和提醒，领航员提醒的过程也是不间断的代码复审过程。

所谓对事不对人，反馈也要注意方式方法。一般来说对人的评价是从以下三个方面展开的。

1.最外层：行为和后果

2.中间层：习惯和动机

3.最内层：本质和固有属性

书中提到了一个“三明治”的方法：

最好是先来一片面包，做好铺垫：强调双方的共同点，从团队共同的愿景讲起，让对方觉得处于一个安全的环境。

然后再把肉放上，这时就可以把建设性的意见（ConstructiveFeedback）加工好，加上生菜、佐料等。怎么准备这块肉也有讲究，在提供反馈时，不宜完全沉溺于过去的陈年谷子烂芝麻，给别人做评价，下结论。这样会造成一种[你就是做得不好，我恨你]的情绪。不妨换个角度，展望将来的结果，强调[过去你做得不够，但是我们以后可以做得更好]。在技术团队里，我们的反馈还是要着重于[行为和后果]这一层面，不要贸然深入到[习惯和动机]、[本质]。除非情况非常严峻，需要触动别人内心深处，让别人悬崖勒马。然后再来一片面包，呼应开头，鼓励对方把工作做好

生活中的沟通也可以借鉴”三明治“方法，从双方基础谈起，再书名建设性意见，最后再鼓励一下对方。似乎，我女朋友训我的时候也是这样的模型，咳咳，扯远了。

总之，结对编程是能加深团队成员了解，快速提高项目进度，1+1>2的一种不错的编程方法。