《构建之法》读书笔记（1）：代码复审与团队沟通

代码复审

代码复审的正确定义：看代码是否在代码规范的框架内正确地解决了问题。

复审的形式

名称	形式	目的
自我复审	自己 v.s. 自己	用同伴复审标准要求自己，高成长
同伴复审	复审者 v.s. 开发者	简便易行
团队复审	团队 v.s. 开发者	严格的规定与流程，覆盖率高。适用于关键代码与不再更新的代码

复审的目的

1. 排查算法逻辑错误（不正确问题，不准确问题与潜在的边界问题）
2. 考虑算法的性能（时间复杂度，空间复杂度）
3. 代码格式与设计规范
4. 杜绝回归性问题
5. 思考可能的改进点与方向
6. 开发经验交流，促进团队成员熟悉代码

复审的步骤

复审前

1. 确保代码成功编译跑通
2. 确保所有代码均通过测试（单元测试，回归测试）
3. 提供代码与文本差异工具（线上git化）

复审中

1. 开发者讲述产出结果，开发逻辑，修改的前因后果。复审者随时提问
2. 开发者逐一提出反馈意见，能回答的当场回答，不能回答的记录todo，会后明确后回复。

复审后

问题修复注意的问题：

1. 探究问题本质，项目中是否会存在类似问题
2. 问题的修复是否影响其他功能
3. 记录修改说明，便于后期维护
4. 告知相关人员

解决问题的三种情况

1. 更正明显的错误
2. 对于无法迅速更正的错误，记录bug
3. 建立常犯错误备忘录，用作后续自我复审
4. 对于细枝末节，设立一个优先级低的工作项目来跟踪处理

复审的核心内容

代码规范

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

1. PEP８
2. 注释
   解释程序是程序本身的工作，注释是解释程序做什么（What），为什么这样做（Why），以及特别注意的地方（Attention）。

设计规范

1. 函数：实现绝大部分功能，只做一件事
2. goto：单一的出口
3. 错误处理

数据与效能情况

1. 处理数据是否准确（来源准确性，覆盖率，过滤条件，关键字段定义，时间范围，空间范围）
2. 考虑数据的噪音情况，结合项目目的考虑是否需要全量数据
3. 如果算法改进引入过多噪音，则不改进（奥卡姆剃刀原则）
4. 考虑算法的时间复杂度（是否过多循环；考虑网络情况）

测试情况

1. 单元测试（覆盖所有代码）
2. 回归测试（审查代码更新）
3. 压力测试（并发）

团队沟通

正确的反馈

反馈的层次

1. 最外层：行为和后果
   当反馈是陈述行为和后果的时候，行为可以改正，后果可以弥补，对方还是有挽回局面的机会。
2. 中间层:习惯和动机
   当反馈上升到攻击对方的习惯和动机，被攻击的一方就比较难表白并且澄清动机
3. 最内层：本质和固有属性
   当攻击深入到核心，被攻击一方已经无法回应，因为目标是自己的固有属性与本质，难以改变
   *任何人都不是完美的，都有可以改进的空间

易于接受的反馈：三明治法则

1. 面包片：做铺垫，强调双方的共同点，从团队共同的愿景讲起，让对方觉得处于一个安全的环境
2. 肉饼：建设性意见，展望未来，强调【你过去做的不够，但是我们以后可以做得更好】（提供反馈的时候不要完全沉湎于过去往事来给对方做评价下结论）
3. 面包片：呼应开头，鼓励对方把工作做好

反馈建议着重于【行为与后果】层面，不要贸然深入【习惯与动机】，【本质与固有属性】的测个面，除非特别严峻，需要触动内心，让人悬崖勒马。

书中观点是邹欣《构建之法》第三版的提炼与总结（添加少许个人观点）。