如果您是通过面试看到的这篇文章: 这里做个前情说明
过去两年中, 我是 APP 组代码质量的负责人我将我针对组内提交的代码提出的问题截图于这个地址中: 我的 Code Review
由于个人代码质量难以在面试中体现, 希望借这篇文章提供一个参考这系列文章, 摘自我个人笔记对 项目的总结 部分, 若感兴趣,欢迎往下阅读
但勿太深入[笑], 我们先建立一个比较浅但全面的了解, 深入的内容不妨留做之后探讨
✏️
HC2&V-Coptr 这个我负责的历时两年的项目结束后, 我试图回溯以前的积累,归纳其中遇到的问题, 各措施实际的效益,及改善空间.
此称为”溯本回原”系列, Code Review 是 ”溯本回原” 的其中一枝.
即使在项目紧急时刻, 我也基本做到看完每一行提交代码并要求团队尽量坚持 Review
现在要回顾花了我们不少时间的 Code Review:
- 实际产生了多大效益
- 通常大家所认为的 “好” 是什么, 有更高效的方式达成这样的效果吗
对我自己而言:
一方面 我在和人胡诌时可以说出一堆好的形容词 低耦合,高内聚 增加维护性 增进团队合作.
Review (理论上)能起到这样的作用, 但这些说法多是给他人看的. 在我脱口而出 ”这什么破代码” 时,肯定没想这些
另一方面 我评判 好 的标准不成体系, 依赖于看到一段代码时, 脑中对代码的判断.
脱离环境, 我很难凭空列出全面的 一条条作为判断依据的标准
这导致一个问题(也不一定是问题) 每一次对代码的看法不完全统一
(这一刻的几条理由, 在下一刻场景切换后, 说不定就忘或不适用; 某刻的”好/坏”可能只是心血来潮)
我要弄清楚:
- 我纠结哪些 “坏” 代码
- 我用什么标准做依据在评判代码, 这些依据能否以成文的形式而非 “感觉” 列出来, 他们的适用性及轻重缓急
最核心的: Code Review 真的很耗费时间 !!!
找到更高效的方式, 让代码问题更少的出现, 减少 Review 的强度
统计内容
到今天, 项目中我们的 Merge Request (2018.4-2020.10) 1000 个, Commit 7000 个,
以这 1000 个 MR 中的 Comment 作为样本
耗时一周末, 过滤了无效评论和评论中讨论过程, 摘选结论性内容, 放在下方
我个人参与 Comment 摘选 230 条, 归类于此: 我的 Code Review . 用于分析:
- 我认为哪些是有问题的代码
- 我之所以会认为一段代码是坏代码, 原因是什么
- 这些指出的问题, 带来的正向收益是什么
正文两个层面分析:
- 共 1372 条有效
Comment, 摘选其中 575 条, 归类于此: 具体代码问题列表 — 团队指出的 .
用于分析:- 大家 Code Review 关注什么问题, 实际帮助我们解决了什么
- 大家 代码/团队 协作中常出现什么问题
- 什么是好代码
- 统计每月
CommitMerge RequestComment代码修改量
统计方法 & 采集的数据: 对 Code Review 的统计方法
分析过程 & 结论在此: 失败的Commit,Merge Request,Comment数据分析
用于分析: Code Review 是否真的带来代码质量提升, 具体提升了多少
本以为可以从图表数据得出一些显而易见的结论, 比如:代码质量提升, 代码量增加了多少百分比等
然而实际情况, 我统计的数据和分析能力还不成熟, 这次的尝试有太多干扰变量. 比如: 假期, 人员变动, 项目冲刺等
而单以代码量而言, 后期与前期,统计增加/修改行数, 整体是持平的.
最终还是结合主观和一定程度上的数据, 得出两个较浅显的结论:
- 后期能在 MR 中找到的问题比例明显低于前期
- 在相同提交习惯下, 后期产生的 Commit 远多于前期 (我将其理解为有效内容最小单位)
…
后续部分还未完成🚧
只有一些零星的分析和思考过程, 不成体系, 就不做摘取了
若您是面试看到这文章, 还请先关注这篇: > 我的 Code Review