本周在考虑阅读材料时，我翻阅了《移山之道》，正好看到这一章：两人合作，心想：正好，我们正值结对作业的紧要关头，书中两人合作的宝贵经验和教诲应当对我们有很大帮助。于是，我开始一边在ddl苦海中扑腾挣扎，一边抽空读完了这一章，确实受益匪浅。
这一章首先由一个时间估计的小故事引入：从北京火车站到八达岭长城需要多久。书中两位同学分别考虑不同情况，给出了截然不同的估计，由此引出项目管理要素三角形：功能、资源和时间。这三者在项目中相互制约，维持其平衡方能做好项目。回想这一周我们奋战的经历，首先时间方面紧缺，我接到班里团支部申优的大锅，要花很多时间收集、撰写材料；张行健同学则有期中考，需要全力复习。同时，我们都有满满当当的课业虎视眈眈地盯着我们，实在是脱身不易。想到班里大多数同学也都是这样的情况，不免轻叹。其次，功能方面又是一大难点。结对作业中的需求总有些朦胧，在群里大家提问后又一步步将要求具体化，还有一些要求是在群里提、很快被水掉的。这要求我们在尽快满足现有功能需求的同时，时刻注意有没有新的功能需要实现，而功能的实现都需要时间。最后是资源，这方面主要在于我们的知识水平。我们对c++的一些使用有基本的了解，也都学过点数据结构，翻着“栈”那一章的书敲敲OPTR\OPEN还是能做的。但dll封装方面我们事前都没涉及过，网上的教程也非常垃圾，耗费了我们许多时间，最终在同组马同学的帮助下磕磕碰碰地实现了。平衡这三方面，确实说来容易做来难。
随后，书中又谈起了单元测试的重要性，坦白说从上一次个人作业开始，我就一直在尝试做单元测试，但始终没能掌握带全局变量的单元测试如何进行。总而言之单元测试的重要性和快速、覆盖广等原则，我大致是体会得真切了，今后有机会一定系统学习。
最后，是与我们结合最紧密的话题：结对编程。正如邓老师所说，结对编程分为领航员和驾驶员的角色，一者负责监督、检查，一者负责实际编码，两者身份定时互换。结对编程的好处主要有合作、信心和交流，且能让代码处于不断“复审”的状态，大大减少bug率。回想这一次编程经历，我们一起讨论架构、轮流实现具体模块，虽然刚开始工作时还不太适应，但渐渐习惯后就能体会到结对的益处。有时某个相似的变量引用出错，或者某个条件分支判断出现了逻辑漏洞，队友之间能很快相互提醒，规避了许多大坑。虽然我们并没有像书上那样严密地分工，实际上我们的分工还是相当随意的，但仍旧感觉很棒。书中将结对编程的过程比作舞蹈，我感觉还是挺恰当的，不过由于课业繁重的原因，我们合作的时间还比较短，从磨合到创造的过程还是有点雷厉风行，希望日后还有机会继续合作。
总而言之，这一章让我加深了对单元测试重要性的认识，了解到项目管理的三角平衡哲学，也体会到了结对编程的优势，希望本次结对编程能画下圆满的句号吧。