标签：
【4.2】
代码风格非常重要。我自己写时会严格注意这一方面。阅读他人代码时也是同样。里面提到了一些规范，可以此为范本。代码可读性太重要了。
【4.3】
摘：关于函数，最重要的原则是：只做一件事，并且要做好。
关于4.3.4中“如何处理C++中的类”这一部分没太读懂，有一些概念还不太清楚，这里先留下疑问，等全书读完再来释疑。
【4.4】
代码复审的目的之一，查错是必然的，但是如果编译通过，想要发现逻辑错误、算法错误就会相对比较困难，也很容易被忽视。针对此处，结对编程的优势就体现出来了。或者在做项目时由团队复审也可达到比较令人满意的效果。
代码复审的步骤很详尽，可做参照。代码复审时必须具备的一种能力——大局观。这跟玩游戏一个道理，重局部而轻整体有时会导致很致命的错误。另外，在代码初步完成之后，复审或调整阶段最好做好相应备注标记，以便后续再次检查阅读。
针对代码复审的核查表部分，我有个很强烈的感受，那就是我对于程序开发和产品设计的共通性的体会越来越强烈。 这份核查表和设计方法论的checklist核心功能完全一致。阶段、步骤、及每阶段每步的主要考量方向都是一致的。概念探索期、产品设计初期、成熟期、内测期、公测期，包括产品需求分析、目标用户分析、干系人分析、竞品收集拆解、功能列表等，诸多理念在精神上都保持了高度一致。
【4.5】
初初接触到结对编程是娄老的课上，当时对软件开发的思考和领悟还不够深刻，只觉得这名词很新鲜、这种形式很有趣，并不能很好的体会到结对编程真正给编程带来的良好影响是什么。但就当时的那门课程来说，我认为虽然我们都规规矩矩的按照老师的要求两人一组，看似很和谐的在实践着结对编程，但几乎没有人能真的说从这种模式中受益。在我看来，最大的问题当然是出在我们自己身上，对自我要求太低、学习目标不够明确等等。然而还有另外一部分原因我认为也不可忽视，课前对结对编程理解太浅，结果就是要么两个程度相似的同学结对但分工不甚合理，或者说仅有分工没有合作；要么两个程度相差较多的同学结对出现“一边倒、一头重”的现象，程度较差的同学简直成了后勤人员，只负责端茶送水按摩揉肩，依赖性极强。我想想要在大学教学中推广这种编程方式，还需在实践之前做足功课，“前戏”做足，学生才能知道“噢，原来不是一人只负责一部分功能代码，编完拉倒那么简单，还需要互审、代码还需要拼接嵌入，也不是一人负责编一人负责看这种等等”。引导，就是要学生"知其然"，"知其所以然"，然后才能"知其如何然"。
现在回过头来反思，对照书中关于“如何结对编程的步骤和要求”，我和薛薛两人在大学后半段做的大创课题还是比较好的践行了结对编程的理念的。效率高，代码质量较好，彼此都从对方身上学到很多、受益很多，也乐于其中。
【4.6】
和薛薛的结对编程过程很顺利，在沟通这方面没出现什么问题。代码的嵌入和整合也没有大的阻断性问题出现。非要说的话，我觉得有一点可以在以后加以改进，结对编程前需要对软件设计、项目需求达成一致，相关变量可在编程开始前就做好约定，这样省去了代码嵌套时的工作量，也一定程度上减少了语意模糊或定义不清导致的bug。
还有就是我和薛薛的代码风格不是特别一致，她趋向于紧凑型，而我是较为宽松型的。也许未来风格统一会更优。
标签：
原文地址：http://www.cnblogs.com/nicolette/p/5005878.html
