构建之法阅读笔记03
代码风格规范
代码风格的原则：简明，易读，无二义性。
- 缩进，4个空格。一些编辑工具中都可以将tab键扩展成为4个空格。不直接用空格键是因为tab键在不同的情况下显示不同的长度。
- 行宽。大概100字符。
- 括号，复杂条件表达式，用括号清楚地表示逻辑优先级 。
- 断行和空白的{}行，每个“{”“}”都独占一行。
- 分行，不要把多条语句放在一行上。
- 命名，匈牙利命名法。
- 下划线，用来分割变量名字中的作用域标注和变量的语义。
- 大小写，多个单词组成的变量名，如果全部都小写，不易读，一个简单的解决方案就是用大小写区分它们。
- 注释，复杂的注释应该放在函数头，很多函数头的注释都用来解释参数的类型等。注释要有必要性。
代码复审
代码复审的形式：自我复审、同伴复审、团队复审
代码复审的目的：
- 找出代码的错误：
a) 编码错误，比如一些碰巧骗过那些编译器的错误。
b) 不符合团队代码规范的地方。
- 发现逻辑错误，程序可以编译通过，但是代码的逻辑是错的。
- 发现算法错误，比如使用的算法不够优化，边界条件有没有处理好等。
- 发现潜在的错误和回归性错误——当前的修改导致以前修复的缺陷有重新出现。
- 发现可能需要改进的地方。
- 传授经验。
代码复审的步骤：
- 代码必须成功地编译。
- 程序员必须测试过代码，用调试器单步执行。
- 程序员必须提供新的代码，以及文件差异分析工具。
- 复审这可以选择面对面的复审、独立复审或其他方式。
- 在面对面的复审中，一般是开发者控制流程，讲述修改的前因后果。
- 复审者必须逐一提供反馈意见。
- 开发者必须负责让所有的问题都得到满意的解释或解答。
- 对于复审的结果双方必须达成一致的意见。
代码复审后序工作：
- 更正明显错误。
- 对于无法很快更正的错误，要在项目管理软件中创建Bug把他们记录下来。
- 把所有的错误记在自己一个“我常犯的错误”表中，作为以后自我复审的第一步。
结对开发
结对开发的好处：
- 在开发层次，结对编程能够提供更好的设计质量和代码质量，两人合作解决问题的能力更强。
- 对开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感。
- 在企业管理层次上，结对能更有效地交流，相互学习和传递经验，分享知识，能更好地应对人员流动。
- 在接结对编程中，任何一段代码都至少被两双眼睛看过，被两个脑袋思考。代码被不断地复审，这样可以避免牛仔式的编程。同时，结对编程避免了“我的代码”还是“他的代码”的问题，这使得代码的责任不属某个人，二是属于两个人，进而属于整个团队，这样能够帮助团队成员建立集体拥有代码的意识，在一定程度上避免了英雄主义。
如何正确地给与反馈。
我们在工作需要对同伴的工作进行反馈，表达感谢，阐明要求，支出不足等等。怎么讲，才能够让对方能够听进去？反馈就是告诉对方你对他的评价。反馈的层次：
- 最外层：行为和后果。行为可改正，后果可以弥补，对方还是有挽回局面的机会。
- 中间层：习惯和动机。被攻击的一方就比较难表白并且澄清动机。
- 最内层：本质和固有属性。被攻击一方已经无法回应，因为攻击的目标是自己的固有属性，无法改变的。涉及到人的本质，也很难改变。
阅读感受：
这是重读构建之法第四章后写的阅读笔记。这一章首先讲到的是代码风格规范的问题。老师在上课的时候也一直强调这个问题。在平时的编程中，我还是认为自己做的不错的。但是有一点我和书上的观点相悖，书上要求花括号都得独自占一行，我却认为这是没有必要的。书上的理由是这样可以看起结构和对应关系。但是我觉得这样占用了很多不必要的空间。虽然在计算机中并不缺少纸张，但是屏幕中显示代码行数是一定，括号占用额外的行就会压缩代码显示的量，让我们一次接收的信息减少，对于把握全局代码不会有影响吗？
