WTF/m
代码回顾是帮助团队养成编写高质量代码的习惯的手段之一。
1. 代码回顾应该...
- 尽早发现代码中存在的问题，并进行修复。
- 提高代码的可读性，降低理解成本，进而降低维护成本。
- 在团队内传播知识，分享经验，互相学习。
- 建立团队代码规范的约定，督促团队养成良好的编程习惯。
❓实现的逻辑错误如何来发现
2. 代码质量
“代码”包括了代码仓库中的所有文件（资源、配置、脚本、文档...）
2.1 可读的代码
一致的代码样式--保持一致避免代码合并频繁冲突，提升阅读代码的舒适度：
- 制表符 还是 空格
- 缩进
- 换行
- 驼峰 还是 下划线 还是...
- 注释
- ...
代码风格本身不影响代码含义，但影响阅读的舒适度，不一致的风格容易产生合并冲突
💡Tips
- 将 IDE 的代码风格配置导出，提交到代码仓库
- 养成随时格式化代码的习惯，或设置保存文件时自动格式化
- 参考
有意义的命名--准确地表达代码的意图，包括业务上的意图（功能）和设计上的意图（架构、模式）
💡Tips
- 使用翻译工具来命名英文变量：https://github.com/xudaolong/CodeVar
- IDE 拼写错误提示
- 遵循业界流行的命名约定（getter/setter、from/to...）
- 考虑非技术人员的可读性要求（可以作为活文档的测试命名，图片等设计资源）
- 自己团队达成的一致命名规范记录到 Wiki 或者仓库中的 README
2.2 优雅的代码
代码坏味道--发现代码之中潜在问题的信号
常见代码坏味道
Android Lint Checks：https://sites.google.com/a/android.com/tools/tips/lint-checks
💡Tips
- 从 TOP3 的代码坏味道开消除：重复代码、过长方法、过大类
- 约定团队自己的阈值（方法最大行数、类最大行数、允许重复代码出现的次数）
- 利用 Code Inspection 发现问题并修正
- 自己编写 lint 检查
2.3 模块化的代码
（反）模式--识别可以复用的代码“套路”，不符合整体架构的代码。
- 测试模式：GWT（3A）、Mock
- 设计模式：23 种 GoF 模式（部分）
- 架构模式：类的职责分类，类之间应该如何交互，如 MV*
- 架构风格：粗粒度的代码组织方式，如整洁架构、响应式风格、组件化、插件化
💡Tips
- 团队选择自己的架构风格和架构模式，记录到 Wiki 或者仓库中的 README
- 将设计模式提取成模块（类、包、库）进行复用
3. 回顾的形式
XP反馈环
3.1 编写时回顾
在第一时间发现代码中的各种问题，并进行修正。
💡Tips
- 结对编程以及 TDD 编写代码
- 随时在 IDE 中格式化代码
- 通过 Code Inspection 发现问题并修正
- 通过命令行 lint 发现问题并修正
3.2 提交前交叉回顾
确保原子提交，提交的代码不是“半成品”。
💡Tips
- Reviewer 提前了解业务上下文（故事卡），便于理解 Author 的讲解
- 期交前运行自动化测试
- 提交前通过 IDE 格式化代码
- 提交前通过 Code Inspection 发现问题并修正
- 提交前通过命令行 lint 发现问题并修正
- 使用 githook 自动完成检查
- 发现问题立即重构
3.3 集成前交叉回顾
PR 强制交叉回顾，确保集成到主干上的代码符合代码规范。跨地域、跨团队协作，无法及时面对面进行交叉回顾时采用。
💡Tips
- 流水线静态扫描验证
- 流水线自动化测试验证
- Author 向 Reviewer 提供更多业务上下文（故事卡）
3.4 集成后集体回顾
定期（每周至少3次）对重点代码进行集体回顾，分享业务知识、技术知识和设计知识。
💡Tips
- 团队中新人很多时、有重大技术重构时，提高回顾的频率
- 提前公布要回顾的代码涉及的业务上下文（故事卡）
- 参与回顾的成员事先熟悉上下文
- 控制回顾的时间（不超过1小时）和代码量（200~300行）
- 回顾前确保环境安全，让大家可以畅所欲言
- 对事不对人，多鼓励少批评
- 回顾之前先对上一次集体回顾的改进项进行跟踪
- 发现问题讨论出改进项（评论、技术卡等等）
- 可以让 Author 以外的成员来讲解
- 主持人控制好时间，不要没完没了的讨论
- 回顾发现的问题要记录下来，落实下来进行跟踪
5. 小结
无时无刻、无处不在
响应变化、持续优化
build-quality-in-legacy-system.jpg
