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