读完第四章《两人合作》的内容后，感觉前半章则是在规范我们的编程代码规范和代码复审，而后半段则是在介绍两人合作工作时的阶段和技巧。

  程序员的代码不仅仅是给给机器看的，更多的是给一起去工作的伙伴看的，所以我们编写的代码要满足代码风格规范和代码设计规范。代码风格其实很简单，他的原则是：简明，易读性，无二义性。最关键的就是“让代码更容易读”。邹老师在文中提出了几个他总结出的习惯:缩进用4个空格；行宽可限定为100字符；用括号更好的表示逻辑优先级，括号都独占一行也可；多个变量的定义不要集中在一行中。程序中的命名也应当适当的简单，在变量前加上有意义的前缀，用“匈牙利命名法”（在一些强类型的语言不适用）；下划线用于分隔变量名字中的作用域标注和变量的语义；所有的类型/类/函数名都用Pascal形式（所有单词的第一个字母都大写），所有变量都用Camel形式（第一个单词全小写，随后单词随Pascal形式）；注释只用ASCII字符，只注释程序用处，注意点。

  而代码设计规范则涉及到程序设计、模块之间的关系、设计模式等方方面面。一个函数就敢一件事，最好用goto使得函数有唯一的出口，要不断验证函数的正确性。对类处理十分重要，各种类型的规范见书p67.

  代码复审的正确定义是看代码是否在“代码规范”的框架内正确的解决问题。代码复审分为自我复审(自己vs自己)、同伴复审（复审者vs开发者）和团队复审（团队vs开发者），其中最基本的是同伴复审。其目的在于找出代码的错误，发现逻辑、算法、潜在和回归性错误，并且可以教育他人，传授经验，熟悉其他领域的相应知识。复审要关注方方面面。有设计规范，有有代码规范，有程序的效能，可读性，可测试性。代码复审的流程十分复杂，详情见书P71.PS;希望这学期末的大作业可以用这个方法操作，改进程序。

  因为有代码复审，所以很多时候可以进行结对编程，两个共同合作，可以形容为驾驶员和领航员的关系，可以使得程序的初始质量会提高，省下很多以后修改、测试的时间。这是个循序渐进的过程，两人相互磨合，相互学习才是重要的，给别人给予正确的反馈。

  说实话，我不太理解4.6.2“如何正确的给予反馈”的介绍，其中最外层（行为和后果），中间层（习惯和动机）和最内层（本质和固有属性）。反正，对于队友的一些错误，可以用一些比较委婉的方式来表达比较好。

《构建之法》读书笔记w4