全栈工程师修炼指南
熊燚(四火)
Oracle 首席软件工程师
32206 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 46 讲
全栈回顾 (1讲)
加餐 (1讲)
全栈工程师修炼指南
15
15
1.0x
00:00/00:00
登录|注册

27 | 特别放送:聊一聊代码审查

代码审查不利于团建不是不做代码审查的正当理由
团队的习惯和流程不是不做代码审查的正当理由
代码审查的能力不够并非代码审查没有价值
项目时间紧不是不做代码审查的理由
审查内容包括帮助理解代码的描述、实际的代码变更主体、测试和结果
每次的代码变更组成一次代码审查的单元
从代码库的主分支上建立并 check out 一个新的分支
审查时,代码要过两遍,第一遍抓主要问题,第二遍看次要问题
及时表达肯定,委婉表达意见
新员工代码、骨架代码的代码审查要更为严格
变更代码的质量要超过当前代码库的平均水准
让团队中的"牛人"在代码审查中发挥作用
每次变更所包含的代码量一定要小
设立团队质量标杆的最佳实践方式
识别出设计的缺陷,找到测试不易发现的问题
团队关系建设和扩大双方影响力的有效方式
个人和团队提升的最佳途径之一
争议的原因并不成立
争议主要集中在不进行代码审查的"原因"或"借口"上
代码变更最少要得到 1~3 个认可才能合并到主分支
盖上"Approved"或"Shipped"戳表示认可和通过
审查者提出问题和建议,变更的作者改进变更的描述、代码主体和测试
代码审查的流程
造成争论的原因:缺乏对代码审查好处的认识和因果逻辑上的混淆
从中学到的习惯、方法和知识让人获益匪浅
低投入、高产出的开发活动
一些小技巧
代码审查的好处
常见的争议
代码审查的流程
代码审查的重要性
代码审查

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

你好,我是四火。
又到了特别放送时间,今天我想聊一聊代码审查(Code Review)。在软件工程师日常的开发工作中,如果要挑出一项极其重要,却又很容易被忽视的工作,在我看来代码审查几乎是无可争议的第一。
代码审查是一个低投入、高产出的开发活动,就我个人而言,我从其中学到的习惯、方法和知识,让我获益匪浅。但是,我也在微博、微信上看到程序员朋友们争论代码审查的必要性,甚至包括很多大厂的程序员,还有一些有着许多年经验的程序员。
一开始我觉得有些不可思议,和代价相比,代码审查的好处实在太多了,这有必要费那么大心思去讨论这个必要性吗?后来我意识到,造成这个争论的原因,既包括缺乏对于代码审查好处的认识,也包括一些因果逻辑上的混淆。我想,今天的特别放送,我就来把代码审查这个事儿聊清楚,希望它能成为你日常开发工作当中认真对待的必选项。
那值得一提的是,对于全栈工程师而言,代码审查又有一点特殊性。因为我们经常要写多个层面的代码,包括前端代码 HTML、CSS、JavaScript,后端逻辑,比如 Java 或者 Python,还很可能写很多的脚本代码,比如 Shell,做各种各样的配置,像是和基于 XML、JSON 的配置文件打交道,还很可能使用 SQL 写持久层的逻辑。这些代码中,既包括命令式的代码,也包括声明式的代码。由于涉及到的代码类型比较广泛,代码审查者就自然会和不同的团队或项目中的角色打交道,也需要在不同的思维模式之间来回切换。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

代码审查在软件工程中扮演着至关重要的角色。本文深入探讨了代码审查的必要性、流程和全栈工程师的特殊性。作者指出,代码审查是一个低投入、高产出的开发活动,能够带来丰富的学习和收获。全栈工程师需要特别关注代码审查的特殊性,因为他们需要处理多个层面的代码,涉及到不同的团队和项目,需要在不同的思维模式之间切换。常见的代码审查流程包括代码变更的提交、审查者提出问题和建议、作者改进代码并进行讨论、最终得到认可和通过等步骤。代码审查能够提高代码质量、减少bug,同时也是一个学习和交流的机会。此外,代码审查还有助于团队关系建设和扩大双方影响力,识别设计缺陷,找到测试不易发现的问题,以及设立团队质量标杆。文章还对一些常见的争议进行了分析,如代码审查耗时、争吵等问题,并提出了解决方案。总之,代码审查对个人和团队提升至关重要,是软件开发中不可或缺的环节。文章还提供了一些小技巧,如控制每次变更的代码量、让团队中的核心成员在代码审查中发挥作用、要求变更代码的质量超过当前代码库的平均水准、对新员工和骨架代码的代码审查要更为严格、及时表达肯定、委婉表达意见以及审查时代码要过两遍等。这些技巧有助于提高代码审查的效率和质量。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《全栈工程师修炼指南》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(6)

  • 最新
  • 精选
  • 丁丁历险记
    笔记 争议项 1 加班累死,代码审查脱慢进度。 2 代码审查做的事无聊。 (改改注释) 3 习惯如此。 价值观差距太大时,换团队。 合适的争论 理越辩越明。 1 个人提升最好途径。 2 团队关系建设,扩大双方影响力。 3 识别设计的缺陷,找到测试不易发现的问题。 4 设立质量标杆。性格习惯。 小技巧 量小 牛人 高于平均 新员工严格 适当委婉 过两遍。 思考题 个人小技巧 1 直接截图,贴上框架代码(为表达意图,往往删掉异常处理)或其它类似实现代码 2 个人习惯,我对一些违背开发原则的事,是和开发同学不断探讨的, 简单如 dry 好判断的,一定让开发把实现抽取出来。 srp dip 这些往往具体问题具体分析,毕竟不能创个变量就上工厂吧,场景是否适合,克制那颗过度封装的心,改为逐步迭代。 3 改完后,会引一些文章。(我一般选开发接受并修改后,一是此刻他心态更平和,二是刚折腾完,手热。这时候方便适当展开。

    作者回复: 👍

    2019-11-11
    5
  • leslie
    提出点个人的理解吧:记得池老师的专利第一季有篇文章<技术leader是否应该写代码>,其实目前技术经理大概有3成的时间在做Code Review。这块曾经和一些同行聊过:就像老师课中所说的,不做基本上上线可能就挂了。 目前Code Review应当有两张方式吧: 一种是强行做规则-违反规则就不让上线,提交不通过,这块可以用工具去实现; 一种就是人为的对比工具和审核,毕竟人写代码的人看不到自己的问题的,除非是公司或者部门这块的把关的,例如:sql代码基本上有DBA审核,DBA自己写的就只能自己反复测,自己挖了坑的话还是要自己填的,这个会做的异常谨慎。 个人觉得Code Review不仅仅重要,不做code review就是挖地雷;自己亲身经历过几次这种事情,这也是为何陈皓老师在他的专栏会去强调这块。好的code review会减少大量的不确定的坑:这个就像我们日常出门上班会确定门是否关好一样。 说个案例吧:从大公司到中小公司做DBA;CTO和我说数据库慢你优化一下,通过索引解决了出现的典型问题。生产上线前我说我把代码检查一遍,PM说我们的代码都测过没问题,我坚持检查一下-为此双休日没休息加班检查;周一我就扔出了不少所谓的慢且没问题的coding,CTO直接全部门发飙-先解决问题再上线。虽历史问题无力解决,不过常规问题减少了不少。 故而觉得不做code review基本山就是背着炸药包前进:什么时候炸了都不知道;只不过这块目前都是技术经理或者公司真正的专业人士在做而已。

    作者回复: 👍

    2019-11-11
    2
  • 学习学个屁
    开会,捋业务逻辑,大家挑刺儿,然后用阿里规范扫描命名注释等
    2020-04-13
    2
  • нáпの゛
    业务和技术缺一不可,说的太对了。 之前一直都是做后端,对前端代码审查感觉有心无力。 只能硬着头皮把前端学起来,没有真正参与开发还是很难提出建设性意见。
    2019-11-14
    2
  • 丁丁历险记
    第二次读,在一个我主推代码审查总被阻碍,最后出问题了拉我救火,哪天皮了,换团队了,换一个然自己能开心的去努力的地方。
    2019-11-27
    1
  • Geek_3b1096
    很有帮助
    2021-01-18
收起评论
显示
设置
留言
6
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部