程序员进阶攻略
胡峰
京东成都研究院技术专家
33679 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 65 讲
蜕变:破茧成蝶 (3讲)
结束语 (1讲)
程序员进阶攻略
15
15
1.0x
00:00/00:00
登录|注册

45 | 代码评审:寄望与哀伤

投入与收益的平衡
团队文化
公司制度
自动检测和控制工具
严格的代码评审规则
时间成本投入
发现潜在缺陷
代码审查速度
发现潜在缺陷率
促进沟通
影响编码心理
降低损失概率
提高代码质量
发现潜在隐患
提升代码质量
提交代码后的自我 Review
代码评审的多重好处
自我 Review
代码评审工具
实践挑战
Google 的代码评审实践
个人态度与接受度
团队人员结构搭配
保障代码评审效果
项目期限 Deadline
代码评审的效用与成本
卡珀斯·琼斯的分析
代码评审的社会性功用
代码评审的初衷
代码评审的作用
现实选择
参考路径
多种困境
理性分析
感性认识
代码评审

该思维导图由 AI 生成,仅供参考

我们都知道代码评审(Code Review)很有用、很重要,但现实中我所经历的和看到的团队,很少有能把代码评审落地得很好,并发挥出其应有作用的。这个问题困扰我已久。

感性认识

代码评审的作用,有一定经验的程序员们想必都会有感性认识。
它是很多软件工程理论和方法学中的重要一环,对于提升代码质量和找出一些潜在隐患很有帮助,如果你有一些正式的代码评审经历过程,想必也能感性认知到其正面作用。但在我过去工作的这些年里,经历了几家公司,数个不同的团队,却几乎没有哪一个会把代码评审作为必要的一环去执行的。
过去,我们总是在线上出现一些奇怪的疑难问题后,一群相关程序员才围坐在一起,打开相关代码来逐行分析,根据线上现场的“尸检”来做事后分析和推导。这样的事后代码分析实际上根本不是代码评审,也完全违背了代码评审的初衷。
代码评审的初衷是提高代码质量,在代码进入生产环境前经过同行评审来发现缺陷,降低损失概率。这一点程序员都好理解,提前的代码评审就像雷达扫描我们重点关注的代码领地,以期发现或明显或隐藏的危险因素。
漫画《火影忍者》里有一种忍术技能:白眼,这种技能有近 360° 的观察范围。程序员在写程序时力求思考全面,不留死角或盲点,但实际死角或盲点总是存在的。随着我们经历和经验的成长,思考和认识得越发全面(越发接近 360°),拥有了近乎 “白眼” 的能力,但即使是像 “白眼” 一样,也依然会存在盲点。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

代码评审在软件开发中扮演着重要角色,然而实际中却很少能够充分发挥其价值。本文从感性认识和理性分析两个角度探讨了代码评审的好处和困境。感性认识部分强调了代码评审对提高代码质量、弥补个人视角盲点以及影响编码心理的重要性,但也指出了时间成本和适用场景的问题。理性分析部分引用了卡珀斯·琼斯的研究,指出代码评审能发现潜在缺陷的能力高于测试,但需要投入大量时间成本。此外,文章还提到了代码评审面临的多种困境,如项目期限紧迫、团队人员结构不合理等。最后,文章提到了一些优秀实践,如谷歌公司对代码评审的严格规定,以及对实施此项制度的挑战。总的来说,代码评审在软件开发中有其重要性,但需要克服困境和挑战才能充分发挥其作用。文章以一个程序员的自我Review为例,强调了自省的重要性,同时也呈现了代码评审的多重好处和挑战。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《程序员进阶攻略》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(15)

  • 最新
  • 精选
  • Quincy
    老师,我有个问题想问,您觉得程序员该不该追求安稳。。我目前校招拿到的offer中私企和国企有点纠结。。。国企安稳,私企发展比较好,但又担心以后裁员的问题。

    作者回复: 你准备一份工作干一辈子吗?

    2018-11-15
    4
    9
  • 黄蓓
    小米的代码评审做的还不错,高级权限能+2,普通权限能+1,每次提交只有+2了才能入库

    作者回复: 这就是工具和流程给予的限制,才方便推动👍

    2018-11-21
    2
    8
  • 我们组还好,之前也讲过必须进行代码评审的,合并代码也必须两个人,且通过架构师评审。 胡哥,咱们同属一家公司的,看样子是不同部门或小组有不同的要求的!

    作者回复: 嗯,公司没有流程没有要求,就是自己团队约定了,要看团队所在业务和接受度。你是哪个部门?

    2018-11-16
    3
  • 心在飞
    我在医疗行业,code review是必要环节,每个user story接受需要填写线上code review记录(50-60号人,跨国家)。如果团队人数较少,5-6个开发,个人比较喜欢线下的code review,大家坐会议室,分享自己想法,吃吃零食,聊聊天,这样气氛会更好点。code review气氛很重要,只评论代码,不接受人身攻击!(你review别人的代码VS你的代码被人review,感觉完全不同) 然后还需要有个资深的架构师,在大家拿不定主意的时候能够拍个板。总之,code review程序员还是受益良多的!

    作者回复: 嗯,行业性质不同,程序的重要性也不同。你们这个过程还是挺不错的,我们基本很难搞成这样

    2018-11-14
    3
  • Allen_Go
    那我公司来说,提交业务代码后发起代码合并请求,小组长因为合并和上线的角色,鉴于锅从天上来的敬畏,都很自觉reviwer一下代码。但是鉴于时间的关系,都只能到达代码逻辑有没有问题的层面。

    作者回复: 能到这个层面已经不容易了吧

    2019-04-10
    1
  • 寇云
    「说到痛点了,时间紧,任务重,没有时间做 code review.」 ----- 是不是悖论呢?就像写UT,写UT浪费时间。但是认识就是错误的,写UT是为了节省时间。code review 的目的也是为了让代码符合规范,可复用。也是为了节省时间。

    作者回复: 要么工具强制执行CR,要不就考验团队智慧了

    2018-11-22
    1
  • Franklin.du
    以前公司没有code review的工具,仅仅是当bug修改以后,等待提交代码时需要指定程序员当场review一下,看下有没有啥没注意到的缺陷。虽然不是很严格的审查,感觉还是有效果的。

    作者回复: 这是在成本和概率间权衡取舍的方式,大部分互联网软件可以接受这个一定比率出错的概率

    2018-11-14
    1
  • 杨少侠
    说到痛点了,时间紧,任务重,没有时间做 code review.

    作者回复: 共同的痛

    2018-11-14
    1
  • LieBrother
    所在的团队没有代码review,代码比较乱,每个人的风格不一样

    作者回复: 风格这个问题不是靠Review来解决的

    2018-12-25
  • 梅子黄时雨
    没有任何代码评审工作的公司或团队,都不值得加入。

    作者回复: 也许没这么绝对吧

    2018-12-18
收起评论
显示
设置
留言
15
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部