全栈工程师修炼指南
熊燚(四火)
Oracle首席软件工程师
立即订阅
2286 人已学习
课程目录
已更新 43 讲 / 共 40 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 从成长角度看,为什么你应该成为全栈工程师?
免费
学习路径 | 怎样成为一名优秀的全栈工程师?
导读 | 如何学习这个专栏?
第一章 网络协议和 Web 接口 (6讲)
01 | 网络互联的昨天、今天和明天:HTTP 协议的演化
02 | 为HTTP穿上盔甲:HTTPS
03 | 换个角度解决问题:服务端推送技术
04 | 工整与自由的风格之争:SOAP和REST
05 | 权衡的艺术:漫谈Web API的设计
06 | 特别放送:北美大厂如何招聘全栈工程师?
第二章 欢迎来到 MVC 的世界 (7讲)
07 | 解耦是永恒的主题:MVC框架的发展
08 | MVC架构解析:模型(Model)篇
09 | MVC架构解析:视图(View)篇
10 | MVC架构解析:控制器(Controller)篇
11 | 剑走偏锋:面向切面编程
12 | 唯有套路得人心:谈谈Java EE的那些模式
13 | 特别放送:选择比努力更重要
第三章 从后端到前端 (7讲)
14 | 别有洞天:从后端到前端
15 | 重剑无锋,大巧不工:JavaScript面向对象
16 | 百花齐放,百家争鸣:前端MVC框架
17 | 不一样的体验:交互设计和页面布局
18 | 千言万语不及一幅画:谈谈数据可视化
19 | 打开潘多拉盒子:JavaScript异步编程
20 | 特别放送:全栈团队的角色构成
第四章 数据持久化 (7讲)
21 | 赫赫有名的双刃剑:缓存(上)
22 | 赫赫有名的双刃剑:缓存(下)
23 | 知其然,知其所以然:数据的持久化和一致性
24 | 尺有所短,寸有所长:CAP和数据存储技术选择
25 | 设计数据持久层(上):理论分析
26 | 设计数据持久层(下):案例介绍
27 | 特别放送:聊一聊代码审查
第五章 寻找最佳实践 (6讲)
28 | Ops三部曲之一:配置管理
29 | Ops三部曲之二:集群部署
30 | Ops三部曲之三:测试和发布
31 | 防人之心不可无:网站安全问题窥视
32 | 和搜索引擎的对话:SEO的原理和基础
33 | 特别放送:聊一聊程序员学英语
第六章 专题 (7讲)
34 | 网站性能优化(上)
35 | 网站性能优化(下)
36 | 全栈开发中的算法(上)
37 | 全栈开发中的算法(下)
38 | 分页的那些事儿
39 | XML、JSON、YAML比较
40 | 全栈衍化:让全栈意味着更多
全栈工程师修炼指南
登录|注册

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

四火 2019-11-11
你好,我是四火。
又到了特别放送时间,今天我想聊一聊代码审查(Code Review)。在软件工程师日常的开发工作中,如果要挑出一项极其重要,却又很容易被忽视的工作,在我看来代码审查几乎是无可争议的第一。
代码审查是一个低投入、高产出的开发活动,就我个人而言,我从其中学到的习惯、方法和知识,让我获益匪浅。但是,我也在微博、微信上看到程序员朋友们争论代码审查的必要性,甚至包括很多大厂的程序员,还有一些有着许多年经验的程序员。
一开始我觉得有些不可思议,和代价相比,代码审查的好处实在太多了,这有必要费那么大心思去讨论这个必要性吗?后来我意识到,造成这个争论的原因,既包括缺乏对于代码审查好处的认识,也包括一些因果逻辑上的混淆。我想,今天的特别放送,我就来把代码审查这个事儿聊清楚,希望它能成为你日常开发工作当中认真对待的必选项。
那值得一提的是,对于全栈工程师而言,代码审查又有一点特殊性。因为我们经常要写多个层面的代码,包括前端代码 HTML、CSS、JavaScript,后端逻辑,比如 Java 或者 Python,还很可能写很多的脚本代码,比如 Shell,做各种各样的配置,像是和基于 XML、JSON 的配置文件打交道,还很可能使用 SQL 写持久层的逻辑。这些代码中,既包括命令式的代码,也包括声明式的代码。由于涉及到的代码类型比较广泛,代码审查者就自然会和不同的团队或项目中的角色打交道,也需要在不同的思维模式之间来回切换。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《全栈工程师修炼指南》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(4)

  • 丁丁历险记
    笔记
    争议项
    1 加班累死,代码审查脱慢进度。
    2 代码审查做的事无聊。 (改改注释)
    3 习惯如此。

    价值观差距太大时,换团队。
    合适的争论 理越辩越明。
    1 个人提升最好途径。
    2 团队关系建设,扩大双方影响力。
    3 识别设计的缺陷,找到测试不易发现的问题。
    4 设立质量标杆。性格习惯。


    小技巧
    量小
    牛人
    高于平均
    新员工严格
    适当委婉
    过两遍。


    思考题 个人小技巧
     1 直接截图,贴上框架代码(为表达意图,往往删掉异常处理)或其它类似实现代码

      2 个人习惯,我对一些违背开发原则的事,是和开发同学不断探讨的,
    简单如 dry 好判断的,一定让开发把实现抽取出来。
    srp dip 这些往往具体问题具体分析,毕竟不能创个变量就上工厂吧,场景是否适合,克制那颗过度封装的心,改为逐步迭代。
     3 改完后,会引一些文章。(我一般选开发接受并修改后,一是此刻他心态更平和,二是刚折腾完,手热。这时候方便适当展开。

    作者回复: 👍

    2019-11-11
    1
  • 丁丁历险记
    第二次读,在一个我主推代码审查总被阻碍,最后出问题了拉我救火,哪天皮了,换团队了,换一个然自己能开心的去努力的地方。
    2019-11-27
  • нáпの゛
    业务和技术缺一不可,说的太对了。
    之前一直都是做后端,对前端代码审查感觉有心无力。
    只能硬着头皮把前端学起来,没有真正参与开发还是很难提出建设性意见。
    2019-11-14
  • 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
收起评论
4
返回
顶部