《构建之法》之结对编程
这一章讲的是结对编程，结对编程的好处很多，有助于提升代码质量，让两个人都对代码负责，防止甩锅扯皮。但是现实是基本没有公司会这么干，毕竟对于很多中小型的公司来说，人力成本还是很高的。书中的一些编码规范倒是值得学习的，包括代码风格与设计规范。
代码规范
代码风格规范
- 1.缩进问题
这个问题因人而异，我个人还是喜欢用tab键的，而且喜欢使用IDE的快捷键进行代码格式化。 - 2.命名
- 在变量名中不要提到类型或其他语法方面的描述。如表示全年假日的变量，不要用arraylistOfholidays，应该直接用holidays
- 避免过多的描述，这样会使变量名很长，不方便阅读
- 如果信息可以从上下文中得到，那么类信息就不必写在变量名中。如在Teacher表中，变量不要写teacherName，应该直接写name
- 大小写：类/函数名用Pascal，变量用Camel
- 3.注释
- 注释是为了解释程序做了什么，为什么这么做，以及要特别注意的地方
- 复杂的注释应该放在函数头
- 注释也要随着程序的修改而不断更新，毕竟一个误导的注释比没有注释更糟糕
程序员讨厌写注释，更讨厌别人不写注释。我自己的注释写的很随意，恐怕只有自己能看懂，这方面要改正。
代码设计规范
- 函数：只做一件事，并且要做好。
好像单一职责原则 - 构造函数
- 不要在构造函数中做复杂的操作，简单初始化所以数据成员即可
- 构造函数不应该返回错误
- 运算符的实现必须非常有效率，如果有复杂的操作，应定义一个单独的函数
深以为然，自己就在判断语句里写过复杂的逻辑，导致维护比较麻烦 - 不要用异常作为逻辑控制来处理程序的主要流程
代码审查
代码审查的目的
- 找出代码的错误
- 发现逻辑错误
- 发现算法错误
- 发现可能需要改进的地方
我所在的团队也做过代码评审，但更多形式大于意义，坐在下面的同事更关心业务，而很少在代码层面上提出意见。所以在轮完一遍之后，便没有后续了。
我是希望看到好的代码的，也是乐于去学习的，比如他们用了好的设计模式或者算法，我就想去抄。
而且阅读优秀的代码也是一种享受，也会激励我更好的编程。毕竟知行要合一，好的编码规范要在做中学。
但我也很怕把自己的屎山代码拉出来给众人看，这种感觉真的不舒服，但也会鞭策我，让我学习和模仿优秀的代码。
做标记
- todo
- review
- bug
我只用过todo，而且是滥用，定期review应该可以将标记清除，毕竟一个一年前的todo，现在也没人敢动，不知道到底有没有实现。
清除无用的代码
很多人想保留尽可能多的代码，因为以后可能会用上，这样导致程序文件里有很多注释掉的代码，这些代码都可以删除，因为源代码控制已经保存了原来的老代码。
这个感触挺深的，注释掉的代码看着很不爽，还有废弃注解之类的东西，感觉没用了干掉就完事了，无用的代码反而误导，明天就去把项目上用不到的代码清除掉。
