1 代码风格规范
- 4个空格的缩进
- 每个{}独占一行
- 不要把多个变量定义在一行上
- 一个类型的成员变量用m_name来命名
- Pascal：所有的类型/类/函数名
- lowerCamel：变量
- 注释是为了解释程序做什么（What），为什么这么做（Why），以及要特别注意的地方，只用ASCII字符，不要用中文
- 函数：只做一件事，并且要做好
- 单一出口
- 不要在构造函数中做复杂的操作，简单初始化所有的数据成员即可
- 看代码是否在代码规范的框架内正确地解决了问题
- 早期斤斤计较于一些细枝末节也是于大局无补的，但是，这些问题并不是不用处理了，我们可以建立一些优先级较低的工作项来跟踪处理
- 目光放长远
- 这么修改之后，有没有别的功能会受影响
- 项目中还有别的地方需要类似的修改吗
- 有没有留下足够的说明，让将来维护代码时不会出现问题
- 对于这样的修改，有没有别的成员需要告知
- 导致问题的根本原因是什么？我们以后如何能自动避免这样的情况再次出现
2 代码设计规范
3 代码复审
4 代码复审的核查表
有没有无用的代码可以清除？（很多人想保留尽可能多的代码，因为以后可能会用上，这样导致程序文件中有很多注释掉的代码，这些代码都可以删除，因为github上已经保存了原来的老代码）
5 结对编程
结对编程可以取得更高的投入产出比
(1) 如何结对编程
- 驾驶员：写设计文档，进行编码和单元测试等XP开发流程
- 领航员：审阅驾驶员的文档；监督驾驶员对编码等开发流程的执行；考虑单元测试的覆盖率；思考是否需要和如何重构来帮助驾驶员解决具体的技术问题。领航员也可以设计TDD中的测试用例
- 驾驶员和领航员不断轮换角色，不要连续工作超过一小时，每工作一小时休息15分钟。领航员要控制时间。
- 主动参与。任何一个任务都首先是两个人的责任，也是所有人的责任。
- 只有水平上的差距，没有级别上的差异。两人结对，尽管可能大家的级别资历不同，但不管在分析、设计或便马上，双方都拥有平等的决策权力
- 设置好结对编程的环境，座位、显示器、桌面等都要能允许两个人舒适地讨论和工作。如果是通过远程结对编程，那么网络、语音通讯和屏幕共享程序要设置好
(2) 影响他人的几种方式
|
方式 |
简介 |
逻辑/感情 |
推/拉 |
注解 |
|
断言 |
就是这样吧，听我的，没错！ |
感情 |
推—主动推动同伴做某事 |
感情很强烈，适用于有充分的信任的同伴。语音、语调、肢体语言都能帮助传递强烈的信息 |
|
桥梁 |
能不能再给我讲讲你的理由…… |
逻辑 |
拉—吸引对方，建立共识 |
给双方充分条件互相了解 |
|
说服 |
如果我们这样做，根据我的分析，我们会有这样的好处，a、b、c…… |
逻辑 |
推—让对方思考 |
有条理，建立在逻辑分析的基础上。及时不能全部说服，对方也可能接受部分意见 |
|
吸引 |
你想过舒适的生活吗？你想在家里发财吗？加入我们吧 |
感情 |
拉—描述理想状态，吸引对方加入 |
可以有效地传递信息，但是要注意信息的准确性。夸大的渲染会降低个人的可信度 |
(3) 如何正确地给予反馈
- 最外层：行为和后果
- 中间层：习惯和动机
- 最内层：本质和基本属性