构建之法阅读笔记03

代码风格规范

代码风格的原则：简明，易读，无二义性。

1. 缩进，4个空格。一些编辑工具中都可以将tab键扩展成为4个空格。不直接用空格键是因为tab键在不同的情况下显示不同的长度。
2. 行宽。大概100字符。
3. 括号，复杂条件表达式，用括号清楚地表示逻辑优先级 。
4. 断行和空白的{}行，每个“{”“}”都独占一行。
5. 分行，不要把多条语句放在一行上。
6. 命名，匈牙利命名法。
7. 下划线，用来分割变量名字中的作用域标注和变量的语义。
8. 大小写，多个单词组成的变量名，如果全部都小写，不易读，一个简单的解决方案就是用大小写区分它们。
9. 注释，复杂的注释应该放在函数头，很多函数头的注释都用来解释参数的类型等。注释要有必要性。

代码复审

代码复审的形式：自我复审、同伴复审、团队复审

代码复审的目的：

1. 找出代码的错误：

　　　　a) 编码错误，比如一些碰巧骗过那些编译器的错误。

　　　　b) 不符合团队代码规范的地方。

1. 发现逻辑错误，程序可以编译通过，但是代码的逻辑是错的。
2. 发现算法错误，比如使用的算法不够优化，边界条件有没有处理好等。
3. 发现潜在的错误和回归性错误——当前的修改导致以前修复的缺陷有重新出现。
4. 发现可能需要改进的地方。
5. 传授经验。

代码复审的步骤：

1. 代码必须成功地编译。
2. 程序员必须测试过代码，用调试器单步执行。
3. 程序员必须提供新的代码，以及文件差异分析工具。
4. 复审这可以选择面对面的复审、独立复审或其他方式。
5. 在面对面的复审中，一般是开发者控制流程，讲述修改的前因后果。
6. 复审者必须逐一提供反馈意见。
7. 开发者必须负责让所有的问题都得到满意的解释或解答。
8. 对于复审的结果双方必须达成一致的意见。

代码复审后序工作：

1. 更正明显错误。
2. 对于无法很快更正的错误，要在项目管理软件中创建Bug把他们记录下来。
3. 把所有的错误记在自己一个“我常犯的错误”表中，作为以后自我复审的第一步。

结对开发

结对开发的好处：

1. 在开发层次，结对编程能够提供更好的设计质量和代码质量，两人合作解决问题的能力更强。
2. 对开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感。
3. 在企业管理层次上，结对能更有效地交流，相互学习和传递经验，分享知识，能更好地应对人员流动。
4. 在接结对编程中，任何一段代码都至少被两双眼睛看过，被两个脑袋思考。代码被不断地复审，这样可以避免牛仔式的编程。同时，结对编程避免了“我的代码”还是“他的代码”的问题，这使得代码的责任不属某个人，二是属于两个人，进而属于整个团队，这样能够帮助团队成员建立集体拥有代码的意识，在一定程度上避免了英雄主义。

如何正确地给与反馈。

我们在工作需要对同伴的工作进行反馈，表达感谢，阐明要求，支出不足等等。怎么讲，才能够让对方能够听进去？反馈就是告诉对方你对他的评价。反馈的层次：

1. 最外层：行为和后果。行为可改正，后果可以弥补，对方还是有挽回局面的机会。
2. 中间层：习惯和动机。被攻击的一方就比较难表白并且澄清动机。
3. 最内层：本质和固有属性。被攻击一方已经无法回应，因为攻击的目标是自己的固有属性，无法改变的。涉及到人的本质，也很难改变。

阅读感受：

         这是重读构建之法第四章后写的阅读笔记。这一章首先讲到的是代码风格规范的问题。老师在上课的时候也一直强调这个问题。在平时的编程中，我还是认为自己做的不错的。但是有一点我和书上的观点相悖，书上要求花括号都得独自占一行，我却认为这是没有必要的。书上的理由是这样可以看起结构和对应关系。但是我觉得这样占用了很多不必要的空间。虽然在计算机中并不缺少纸张，但是屏幕中显示代码行数是一定，括号占用额外的行就会压缩代码显示的量，让我们一次接收的信息减少，对于把握全局代码不会有影响吗？