设计模式之美
王争
前Google工程师,《数据结构与算法之美》专栏作者
立即订阅
25422 人已学习
课程目录
已完结 113 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 (1讲)
开篇词 | 一对一的设计与编码集训,让你告别没有成长的烂代码!
免费
设计模式学习导读 (3讲)
01 | 为什么说每个程序员都要尽早地学习并掌握设计模式相关知识?
02 | 从哪些维度评判代码质量的好坏?如何具备写出高质量代码的能力?
03 | 面向对象、设计原则、设计模式、编程规范、重构,这五者有何关系?
设计原则与思想:面向对象 (11讲)
04 | 理论一:当谈论面向对象的时候,我们到底在谈论什么?
05 | 理论二:封装、抽象、继承、多态分别可以解决哪些编程问题?
06 | 理论三:面向对象相比面向过程有哪些优势?面向过程真的过时了吗?
07 | 理论四:哪些代码设计看似是面向对象,实际是面向过程的?
08 | 理论五:接口vs抽象类的区别?如何用普通的类模拟抽象类和接口?
09 | 理论六:为什么基于接口而非实现编程?有必要为每个类都定义接口吗?
10 | 理论七:为何说要多用组合少用继承?如何决定该用组合还是继承?
11 | 实战一(上):业务开发常用的基于贫血模型的MVC架构违背OOP吗?
12 | 实战一(下):如何利用基于充血模型的DDD开发一个虚拟钱包系统?
13 | 实战二(上):如何对接口鉴权这样一个功能开发做面向对象分析?
14 | 实战二(下):如何利用面向对象设计和编程开发接口鉴权功能?
设计原则与思想:设计原则 (12讲)
15 | 理论一:对于单一职责原则,如何判定某个类的职责是否够“单一”?
16 | 理论二:如何做到“对扩展开放、修改关闭”?扩展和修改各指什么?
17 | 理论三:里式替换(LSP)跟多态有何区别?哪些代码违背了LSP?
18 | 理论四:接口隔离原则有哪三种应用?原则中的“接口”该如何理解?
19 | 理论五:控制反转、依赖反转、依赖注入,这三者有何区别和联系?
20 | 理论六:我为何说KISS、YAGNI原则看似简单,却经常被用错?
21 | 理论七:重复的代码就一定违背DRY吗?如何提高代码的复用性?
22 | 理论八:如何用迪米特法则(LOD)实现“高内聚、松耦合”?
23 | 实战一(上):针对业务系统的开发,如何做需求分析和设计?
24 | 实战一(下):如何实现一个遵从设计原则的积分兑换系统?
25 | 实战二(上):针对非业务的通用框架开发,如何做需求分析和设计?
26 | 实战二(下):如何实现一个支持各种统计规则的性能计数器?
设计原则与思想:规范与重构 (11讲)
27 | 理论一:什么情况下要重构?到底重构什么?又该如何重构?
28 | 理论二:为了保证重构不出错,有哪些非常能落地的技术手段?
29 | 理论三:什么是代码的可测试性?如何写出可测试性好的代码?
30 | 理论四:如何通过封装、抽象、模块化、中间层等解耦代码?
31 | 理论五:让你最快速地改善代码质量的20条编程规范(上)
32 | 理论五:让你最快速地改善代码质量的20条编程规范(中)
33 | 理论五:让你最快速地改善代码质量的20条编程规范(下)
34 | 实战一(上):通过一段ID生成器代码,学习如何发现代码质量问题
35 | 实战一(下):手把手带你将ID生成器代码从“能用”重构为“好用”
36 | 实战二(上):程序出错该返回啥?NULL、异常、错误码、空对象?
37 | 实战二(下):重构ID生成器项目中各函数的异常处理代码
设计原则与思想:总结课 (3讲)
38 | 总结回顾面向对象、设计原则、编程规范、重构技巧等知识点
免费
39 | 运用学过的设计原则和思想完善之前讲的性能计数器项目(上)
40 | 运用学过的设计原则和思想完善之前讲的性能计数器项目(下)
设计模式与范式:创建型 (7讲)
41 | 单例模式(上):为什么说支持懒加载的双重检测不比饿汉式更优?
42 | 单例模式(中):我为什么不推荐使用单例模式?又有何替代方案?
43 | 单例模式(下):如何设计实现一个集群环境下的分布式单例模式?
44 | 工厂模式(上):我为什么说没事不要随便用工厂模式创建对象?
45 | 工厂模式(下):如何设计实现一个Dependency Injection框架?
46 | 建造者模式:详解构造函数、set方法、建造者模式三种对象创建方式
47 | 原型模式:如何最快速地clone一个HashMap散列表?
设计模式与范式:结构型 (8讲)
48 | 代理模式:代理在RPC、缓存、监控等场景中的应用
49 | 桥接模式:如何实现支持不同类型和渠道的消息推送系统?
50 | 装饰器模式:通过剖析Java IO类库源码学习装饰器模式
51 | 适配器模式:代理、适配器、桥接、装饰,这四个模式有何区别?
52 | 门面模式:如何设计合理的接口粒度以兼顾接口的易用性和通用性?
53 | 组合模式:如何设计实现支持递归遍历的文件系统目录树结构?
54 | 享元模式(上):如何利用享元模式优化文本编辑器的内存占用?
55 | 享元模式(下):剖析享元模式在Java Integer、String中的应用
设计模式与范式:行为型 (18讲)
56 | 观察者模式(上):详解各种应用场景下观察者模式的不同实现方式
57 | 观察者模式(下):如何实现一个异步非阻塞的EventBus框架?
58 | 模板模式(上):剖析模板模式在JDK、Servlet、JUnit等中的应用
59 | 模板模式(下):模板模式与Callback回调函数有何区别和联系?
60 | 策略模式(上):如何避免冗长的if-else/switch分支判断代码?
61 | 策略模式(下):如何实现一个支持给不同大小文件排序的小程序?
62 | 职责链模式(上):如何实现可灵活扩展算法的敏感信息过滤框架?
63 | 职责链模式(下):框架中常用的过滤器、拦截器是如何实现的?
64 | 状态模式:游戏、工作流引擎中常用的状态机是如何实现的?
65 | 迭代器模式(上):相比直接遍历集合数据,使用迭代器有哪些优势?
66 | 迭代器模式(中):遍历集合的同时,为什么不能增删集合元素?
67 | 迭代器模式(下):如何设计实现一个支持“快照”功能的iterator?
68 | 访问者模式(上):手把手带你还原访问者模式诞生的思维过程
69 | 访问者模式(下):为什么支持双分派的语言不需要访问者模式?
70 | 备忘录模式:对于大对象的备份和恢复,如何优化内存和时间的消耗?
71 | 命令模式:如何利用命令模式实现一个手游后端架构?
72 | 解释器模式:如何设计实现一个自定义接口告警规则功能?
73 | 中介模式:什么时候用中介模式?什么时候用观察者模式?
设计模式与范式:总结课 (2讲)
74 | 总结回顾23种经典设计模式的原理、背后的思想、应用场景等
75 | 在实际的项目开发中,如何避免过度设计?又如何避免设计不足?
开源与项目实战:开源实战 (14讲)
76 | 开源实战一(上):通过剖析Java JDK源码学习灵活应用设计模式
77 | 开源实战一(下):通过剖析Java JDK源码学习灵活应用设计模式
78 | 开源实战二(上):从Unix开源开发学习应对大型复杂项目开发
79 | 开源实战二(中):从Unix开源开发学习应对大型复杂项目开发
80 | 开源实战二(下):从Unix开源开发学习应对大型复杂项目开发
81 | 开源实战三(上):借Google Guava学习发现和开发通用功能模块
82 | 开源实战三(中):剖析Google Guava中用到的几种设计模式
83 | 开源实战三(下):借Google Guava学习三大编程范式中的函数式编程
84 | 开源实战四(上):剖析Spring框架中蕴含的经典设计思想或原则
85 | 开源实战四(中):剖析Spring框架中用来支持扩展的两种设计模式
86 | 开源实战四(下):总结Spring框架用到的11种设计模式
87 | 开源实战五(上):MyBatis如何权衡易用性、性能和灵活性?
88 | 开源实战五(中):如何利用职责链与代理模式实现MyBatis Plugin?
89 | 开源实战五(下):总结MyBatis框架中用到的10种设计模式
开源与项目实战:项目实战 (9讲)
90 | 项目实战一:设计实现一个支持各种算法的限流框架(分析)
91 | 项目实战一:设计实现一个支持各种算法的限流框架(设计)
92 | 项目实战一:设计实现一个支持各种算法的限流框架(实现)
93 | 项目实战二:设计实现一个通用的接口幂等框架(分析)
94 | 项目实战二:设计实现一个通用的接口幂等框架(设计)
95 | 项目实战二:设计实现一个通用的接口幂等框架(实现)
96 | 项目实战三:设计实现一个支持自定义规则的灰度发布组件(分析)
97 | 项目实战三:设计实现一个支持自定义规则的灰度发布组件(设计)
98 | 项目实战三:设计实现一个支持自定义规则的灰度发布组件(实现)
开源与项目实战:总结课 (1讲)
99 | 总结回顾:在实际软件开发中常用的设计思想、原则和模式
设计模式之美
15
15
1.0x
00:00/00:00
登录|注册

加餐三 | 聊一聊Google是如何做Code Review的

王争 2020-06-24
100 篇的正文已经全部结束了,估计你学得也有点累了吧?时隔这么久,正文终于结束了,从今天起,我们继续加餐内容。
跟正文内容相比,加餐内容我希望尽量轻松有趣,帮你拓展知识面,主要是课后的一些小分享,有的会以讲故事为主,但我也希望它能给你带来收获。如果能够引发你的思考和共鸣那就更好了。所以,我也希望你在留言区,多说说自己的感受和看法,多多与我互动。
话不多说,让我们正式开始今天加餐的内容吧!

为什么国内企业不重视 Code Review?

在专栏第 80 讲中,我列举了 Code Review 的重要性,在项目中执行 Code Review 会带来哪些好处,以及如何克服一些常见的难题,在项目中启动 Code Review 等等。今天,我们想再继续这个话题,和你聊一下 Code Review。不过,我刚才也说了,今天的内容会相对轻松一些,我会主要给你讲讲我在 Google 做 Code Review 的一些经验和心得。
我们都知道,Google 在 Code Review 方面做得非常好,可以说是很多公司学习的榜样。从我个人的经历来说,我的技术成长相当大的一部分得益于当年在 Google 的 Code Review。所以,我也希望更多的同行能意识到 Code Review 的重要性,能够在项目中推行 Code Review,受益于 Code Review。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《设计模式之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(31)

  • tingye
    国内code review难推广的一个原因可能也和文化有关,老外习惯直来直往评价和就事论事,中国人为人处世讲究委婉,要面子,特别同级别同事间往往不好意思直接指出别人的问题

    作者回复: 说的太对了

    2020-06-24
    3
    21
  • Jxin
    原因:
    1.缺少追求卓越的氛围。先run的理念退化成了能run就行。
    2.招聘要求上基本都会有代码设计能力,编码规范,甚至代码洁癖的项。但实际上基本不提,顶多背几个设计模式。那么编码能力就变得很鸡肋,因为它与薪资几乎无关。叫好不叫坐大概就是这个意思。
    3.重构本是小步快跑,但我看到的大部分都是重写,而非重构。这就导致认知中的重构成本很高,进而就会排斥。而只写代码不重构代码,在编码能力的提升上是很缓慢的。如果把识别坏代码的能力看作是一把尺子。经常重构的人,这把尺子的精度是一毫米,只写功能的人精度只有一分米。那么在识别坏味道评估改动点时就会很模糊,模糊就更不敢下手,恶性循环。

    办法:
    1.氛围,国内的开源项目先开始讲究,带个氛围。
    2.将编码能力和算法放在同等位置看待。其实编码能力强的人,往往意味着思路清晰,讲究。这种人工作能力一般差不了。
    3.普及重构理应小步快跑的理念。把事情拆小,把小事情做好,都很重要。重构需要会拆解工作,然后也别看重构手法简单,刻意训练后也会有质变。(重构是提高普遍认知的有效手段,只有认知上去了codereview才能被 重视)
    2020-06-24
    3
    10
  • wkq2786130
    我刚开始也不理解code review ,直到有一天发现自己写的代码自己读不懂,然后开始优化,开始写注释,理清主要逻辑,开始分层,开始使用通俗易懂的命名,后来逐渐意识到code review的好处
    2020-06-24
    10
  • Monday
    公司让我等制定code review规范,并推广。
    ps:现在公司情况:code review 各自(组)为政。
    我了解的几个组是只在乎功能正确性,不怎么在乎编码规范/风格、命名风格。各组的评审流程也不一样。
    我现在的思路
    1、收集各组的评审方式及规范
    2、整合各组的方式和规范结合业界的最佳实践(如google)制定出适合我司的一套规范与流程1.0
    3、推广使用,收集反馈,补充和优化规范和流程,避免形式化

    小争哥或各位学友有哪些好的建议呢,谢谢

    作者回复: 不错,可以先把你列举的这些执行到位再说~

    2020-06-29
    5
  • 皮特尔
    之前好像听池老师说过:极客时间团队是有Code Review的。
    感觉这件事主要还是看团队吧。

    作者回复: 有很多团队说有,实际上算不上有。。走个过场而已。。

    2020-06-26
    2
    5
  • progyoung
    就个人的工作经历来看,很多互联网公司程序员的职责就是完成业务,没有功能bug是第一位的需求,至于代码质量,在leader的眼中根本就不重要。而且一个需求提出之后,恨不得马上就能看到结果,发布上线。在这样的大环境之下,996盛行,code review就被认为是浪费时间,怎么能推行的开呢?
    2020-06-24
    5
  • K战神
    有一次看到新人代码有很多问题时,我马上进行了提交限制权限。每一次提交的代码都发合并请求,我会每一句仔细看,然后评论,改完,再看再评论。效果显著,我们一起根据问题对应到代码整洁之道这本书,看看命中了拿着坑。

    还有一次我们同级别的审查我的代码,我当时确实比较排斥,我觉得同级别有经验的一起互相审核,感觉难度确实有些大,大家都在极力表述自己是对的,反而再互相理论。

    推行代码审查,前几步确实很费时间,很费精力,后面慢慢就好了,然后这种对代码的极致追求会成为习惯
    2020-06-29
    3
  • Jackey
    能做的就是在自己的团队中大力推广code review,不符合规范的代码一定不能进入repo
    2020-06-24
    3
  • 翠羽香凝
    我同时在美资外企和中国本土企业工作过,看到了另一个方面的问题:在美资企业,往往技术领导者有很大的权限,甚至很多公司的最高领导自己就是技术出身,对技术非常重视,也重视代码质量。
    而中国的本土企业,大部分公司的领导都是销售,财务出身,有些甚至来自投行,把PPT看得重于一切,至于代码质量,抱歉,领导可能重来不知道代码还有质量这回事,不是应该完成功能通过测试就OK了吗?
    而且,大部分的项目都很短命,就像中国的PPT文化一样,开发项目的目的就是“骗骗你”,钱到手了,项目的是否易于维护,是否易于扩展都并不重要,领导不关心,抱歉,你还真以为你要做一个Facebook呢?看看中国有几个BAT就知道了。
    2020-07-04
    2
  • 西门吹牛
    我们公司,从18年底就开始接入code review了,然后到现在,大家都把code review当成了一个过场,哎,那谁给我过下代码。个人感觉,code review带来的益处是需要个长期积累的过程,短时间,对个人,对公司来说,带来的益处也许并不明显。但是坚持下去,时间一久,就会得到意外的收获。code review更加是一种态度,一种责任
    2020-06-29
    2
  • 焕伦蔡
    个人愚见,无法推行code review的原因:
    1.很多公司项目本来也就做不大,大不了就费点时间重写呗,有些项目甚至就是做死了,例如Java来说可能一个SSM就搞定了,然后也就没有然后了
    2.团队水平有限,团队没有一两个确实有能力的人,都不知道什么样的代码才是优秀的代码,code review就会变得很耗时费力,基本到后面就都没人做了
    解决方法:
    1.看过《高效能程序员的修炼》一书,觉得有一点很好,那就是确保有多一双眼睛盯着你的代码
    2.制定最简单基础的规范,比如说命名为驼峰,不能使用拼音,超过一屏的函数得拆分,然后强制执行,所有人按着这个标准,有时候简单暴力就是最有效的
    2020-06-29
    2
  • 黄林晴
    最后一段说的很扎心
    等你当了领导 有了话语权 ……
    可能坚持review 的人 由于让同事觉得太苛刻
    伤面子,永远很难晋升
    2020-06-29
    2
  • 迷羊
    感觉还是没有会 Code Review 的人带

    作者回复: 杨哥,我带你!

    2020-06-24
    5
    2
  • 虢國技醬
    我觉得code review好处之一就是帮助部分同学提高编码技能;毕竟工作不像在学校,写的不好的同学老师会手把手教你,code review让大家看到优秀的,也看到槽糕的
    2020-06-24
    2
  • coco張
    我们公司也有code review,外企嘛,很多形式都会有的,但是效果不是特别好,关键还是reviewer的能力不足以支撑给出意见,流程上是加上了,但是merge以后还是一改再改
    2020-07-03
    1
  • 微末凡尘
    以前写代码从来没有注意代码质量的问题,而是完成功能为第一步,然后就没有然后了,直到我现在入职一家新公司,虽然公司不大,但是有很好的CR习惯,每次提交代码,leader都会review我的代码并且非常细心,耐心的给出修改意见,有助于我代码水平的提高,现在写代码时会不自觉地注意代码书写的规范,因为感觉总有一双眼睛盯着你在。。。
    2020-07-02
    1
  • 全炸攻城狮
    code review的前提是知道什么是好代码,以及严格的编码规范。第一点需要有经验的工程师,具备review其他人代码能力的leader,第二点需要借助工具如lint。还有一点是要形成习惯,当成开发任务中的正常环节就好了
    2020-07-01
    1
  • 丹枫无迹
    确实,最主要的问题是没有会 Code Review 的人带,不知道怎么去开展。如果完全靠自己摸索,那进展就会缓慢,迟迟不出效果,即便老板一开始是支持的,后面也会开始怀疑,最后可能就是不了了之。
    2020-06-29
    1
  • cricket1981
    想了解下Google是如何将这些规范落地的?有什么具体措施国内公司能够借鉴吗?道理大家都懂,但实际操作起来怎么监督实施呢?

    作者回复: 对于不满足规范的,坚决不让提交上去。就看有么有决心执行了。

    2020-06-27
    1
  • 黄骏
    有时候review同事的pr,一些语法和编程风格的问题比较多,好像重视程度也不够,反馈后新的pr仍然如此,对reviewer来说就不太友好了,觉得我提的问题太傻了么?

    作者回复: 反馈给领导层,让领导层推编程规范~

    2020-06-26
    1
收起评论
31
返回
顶部