程序员进阶攻略
胡峰
京东成都研究院技术专家
立即订阅
7526 人已学习
课程目录
已完结 65 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 程序行知:走在同样的路上,遇见自己的风景
免费
征途:启程之初 (4讲)
01 | 初心:为什么成为一名程序员?
02 | 初惑:技术方向的选择
03 | 初程:带上一份技能地图
04 | 初感:别了校园,入了江湖
修炼:程序之术 (10讲)
05 | 架构与实现:它们的连接与分界?
06 | 模式与框架:它们的关系与误区?
07 | 多维与视图:系统设计的思考维度与展现视图
08 | 代码与分类:工业级编程的代码分类与特征
09 | 粗放与精益:编程的两种思路与方式
10 | 炫技与克制:代码的两种味道与态度
11 | 三阶段进化:调试,编写与运行代码
12 | Bug的空间属性:环境依赖与过敏反应
13 | Bug的时间属性:周期特点与非规律性
14 | Bug的反复出现:重蹈覆辙与吸取教训
修行:由术入道 (24讲)
15 | 根源:计划的愿景——仰望星空
16 | 方式:计划的方法——脚踏实地
17 | 检视:计划的可行——时间与承诺
18 | 评估:计划的收获——成本与收益
19 | 障碍:从计划到坚持,再到坚持不下去的时候
20 | 执行:从坚持到持续,再到形成自己的节奏
21 | 信息:过载与有效
22 | 领域:知识与体系
23 | 转化:能力与输出
24 | 并行:工作与学习
25 | 时间:塑造基石习惯(上)——感知与测量
26 | 时间:塑造基石习惯(下)——切割与构建
27 | 试试:一种“坏”习惯
28 | 提问:从技术到人生的习惯
29 | 偏好:个人习惯的局限与反思
30 | 写作:写字如编码
31 | 画图:一图胜千言
32 | 演讲:表达的技术
33 | 定义:阶梯与级别
34 | 晋升:评定与博弈
35 | 关系:学徒与导师
36 | 核心:安全与效率——工程技术的两个核心维度
37 | 过程:规模与协作——规模化的过程方法
38 | 思维:科学与系统——两类问题的两种思维解法
徘徊:道中彷徨 (15讲)
39 | 职业倦怠:如何面对?
40 | 局部最优:如何逃离?
41 | 沟通之痛:如何改变?
42 | 技术停滞:如何更新?
43 | 无法实现:困扰与反思
44 | 完成作品:理想与现实
45 | 代码评审:寄望与哀伤
46 | 人到中年:失业与恐惧
47 | 该不该去创业公司?
48 | 该不该接外包?
49 | 技术干货那么多,如何选?
50 | 技术分歧,如何决策?
51 | 技术债务,有意或无意的选择?
52 | 选择从众,还是唯一?
53 | 选择工作,还是生活?
寻路:路在何方 (7讲)
54 | 侠客行:一技压身,天下行走
55 | 江湖路:刀剑相接,战场升级
56 | 御剑流:一击必杀,万剑归心
57 | 三维度:专业、展现与连接
58 | 三人行:前辈、平辈与后辈
59 | 三角色:程序员、技术主管与架构师
60 | 三视角:定位、自省与多维
蜕变:破茧成蝶 (3讲)
61 | 工作之余,专业之外
62 | 跨越断层,突破边界
63 | 成长蓝图,进化跃迁
结束语 (1讲)
尾声 | 始于知,终于行
程序员进阶攻略
登录|注册

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

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

感性认识

代码评审的作用,有一定经验的程序员们想必都会有感性认识。
它是很多软件工程理论和方法学中的重要一环,对于提升代码质量和找出一些潜在隐患很有帮助,如果你有一些正式的代码评审经历过程,想必也能感性认知到其正面作用。但在我过去工作的这些年里,经历了几家公司,数个不同的团队,却几乎没有哪一个会把代码评审作为必要的一环去执行的。
过去,我们总是在线上出现一些奇怪的疑难问题后,一群相关程序员才围坐在一起,打开相关代码来逐行分析,根据线上现场的“尸检”来做事后分析和推导。这样的事后代码分析实际上根本不是代码评审,也完全违背了代码评审的初衷。
代码评审的初衷是提高代码质量,在代码进入生产环境前经过同行评审来发现缺陷,降低损失概率。这一点程序员都好理解,提前的代码评审就像雷达扫描我们重点关注的代码领地,以期发现或明显或隐藏的危险因素。
漫画《火影忍者》里有一种忍术技能:白眼,这种技能有近 360° 的观察范围。程序员在写程序时力求思考全面,不留死角或盲点,但实际死角或盲点总是存在的。随着我们经历和经验的成长,思考和认识得越发全面(越发接近 360°),拥有了近乎 “白眼” 的能力,但即使是像 “白眼” 一样,也依然会存在盲点。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《程序员进阶攻略》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

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

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

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

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

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

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

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

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

    2018-11-14
    2
  • 寇云
    「说到痛点了,时间紧,任务重,没有时间做 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
  • Allen_Go
    那我公司来说,提交业务代码后发起代码合并请求,小组长因为合并和上线的角色,鉴于锅从天上来的敬畏,都很自觉reviwer一下代码。但是鉴于时间的关系,都只能到达代码逻辑有没有问题的层面。

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

    2019-04-10
  • LieBrother
    所在的团队没有代码review,代码比较乱,每个人的风格不一样

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

    2018-12-25
  • 行下一首歌
    没有任何代码评审工作的公司或团队,都不值得加入。

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

    2018-12-18
  • third
    把自己想象成外人,用第三者视角看自己

    代码评审:提前对代码进行检测,有较高概率降低出错率

    多种困境
    时间成本
    效果差
    利益不好分配
    总有刁民想害朕

    自省
    自我的成长就是自省开始的。
    2018-12-15
收起评论
11
返回
顶部