设计模式之美
王争
前Google工程师,《数据结构与算法之美》专栏作者
立即订阅
23374 人已学习
课程目录
已更新 98 讲 / 共 102 讲
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种设计模式
开源与项目实战:项目实战 (5讲)
90 | 项目实战一:设计实现一个支持各种算法的限流框架(分析)
91 | 项目实战一:设计实现一个支持各种算法的限流框架(设计)
92 | 项目实战一:设计实现一个支持各种算法的限流框架(实现)
93 | 项目实战二:设计实现一个通用的接口幂等框架(分析)
94 | 项目实战二:设计实现一个通用的接口幂等框架(设计)
不定期加餐 (3讲)
加餐一 | 用一篇文章带你了解专栏中用到的所有Java语法
加餐二 | 设计模式、重构、编程规范等相关书籍推荐
春节特别加餐 | 王争:如何学习《设计模式之美》专栏?
免费
设计模式之美
15
15
1.0x
00:00/00:00
登录|注册

80 | 开源实战二(下):从Unix开源开发学习应对大型复杂项目开发

王争 2020-05-06
上两节课,我们分别从代码编写、研发管理的角度,学习了如何应对大型复杂软件开发。在研发管理这一部分,我们又讲到比较重要的几点,它们分别是编码规范、单元测试、持续重构和 Code Review。其中,前三点在专栏的理论部分都有比较详细的讲解,而唯独 Code Review 我们还没有讲过,所以,今天我就借机会和你补充一下这一部分的内容。
很多年前,我跟一个有十几年研发经验的某一线大厂的技术专家聊天,聊天中我提起了 Code Review,他便对 Code Review 一顿否定。他说,Code Review 比较浪费时间,往往会虎头蛇尾,不可能在企业中很好地落地执行。当我又提起,Code Review 在 Google 执行得很好,并且是已经习以为常的开发流程的时候,他竟然说这绝对不可能。
一个技术不错,可以玩转各种架构、框架、中间件的资深 IT 从业者,居然对 Code Review 有如此的偏见,这到底是哪里出了问题呢?我觉得问题主要还是出自认知上。
所以,今天,我并不打算讲关于如何做 Code Review 的方法论,我更希望充当一个 Code Review 布道师的角色,讲一讲为什么要进行 Code Review,Code Review 的价值在哪里,让你重视、认可 Code Review。因为我觉得,只要从认知上接受了 Code Review,对于高智商的 IT 人群来说,搞清楚如何做 Code Review 并不是件难事。而且,Google 也开源了它自己的 Code Review 最佳实践,网上很容易搜到,你完全可以对照着来做。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《设计模式之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(25)

  • xindoo
    https://github.com/xindoo/eng-practices-cn 我们翻译的谷歌工程实践中文版,老师说的谷歌开源的code review就在这,欢迎查阅。
    2020-05-06
    33
  • 天华
    如果老师能把过去cr经验,需要注意的关键点整理出来就更好了
    2020-05-06
    9
  • + +
    所在公司非常重视code review
    需要至少得到两个人的approved
    分别是 业务组一个和架构组一个
    刚来公司时的第一次代码提交 有20多个comments
    现在也能给别人review了
    2020-05-06
    6
  • 小黑
    能分享下review的checklist么
    2020-05-06
    5
  • 小喵喵
    如果老师能讲解一些实战就更好了。多举例说明这段代码审查出什么问题以及如何修改。
    2020-05-06
    1
    5
  • Jackey
    团队现在的code review基本流于形式了,想要改善感觉也没什么太好的办法,太多人自由惯了…只能做好自己了
    2020-05-06
    4
  • yu
    先code review,还是先联调提测呢。
    如果先code review,项目时间表是没安排这个时间的,review+改应该需要个1~2天。
    如果先联调提测,review出问题后也没法改了。
    之前我们code review,是后端写完代码,边跟前端联调边review,因为是一个新的业务项目,review完之后要改的比较多,前端一直反映联调不流畅。
    2020-05-14
    3
  • Richie
    如何看待:
    一、Jeff Dean提交代码前都会编译以及运行他的代码,目的仅仅是为了检验编译器以及链接器是否有问题。
    二、编译器从来不会给Jeff Dean警告,相反,Jeff Dean会给编译器警告。
    2020-05-11
    3
  • Heaven
    Code Review是个好东西,懂得人不少,可是能够执行起来的难上加难,大厂何尝不是,好处能列一大堆,可是咱不是领导,没有带头的能力,自己一个人搞Code Review起不了什么作用,只能各扫门前雪,自己对自己的些重构罢了
    2020-05-06
    3
  • jaryoung
    code review,个人觉得国内至少有一半的公司都没有,至少一半的一半是流于形式。check list:
    1. 编码规范(借助工具,例如国内的p3c,还有就是借助checkstyle等工具)
    2. 编码技巧(例如,提前终止错误),慢慢建立自己公司的知识库。
    最后,就是坚持坚持再坚持,教育教育再教育。
    2020-05-06
    2
  • 小晏子
    非常赞成code review,在我的平时工作中,code review非常严格,遇到的问题就是像文中提到的,一个特性开发好了之后要好长一段时间才能合入到主干分支,不过这个有个好处是上线bug确实很少,代码质量也比较高!
    2020-05-06
    2
  • 墨雨
    破窗效应
    2020-05-13
    1
  • 目前所在的公司有code review的习惯,但是仅限于leader来review,而且并不严格,主要保证逻辑的正确和代码的可读性,我个人在来到公司之后看了代码整洁之道和effective java这两本书,感觉对写出整洁代码有一定的帮助
    2020-05-07
    1
  • will
    还是很有必要进行review的,这个也是个学习的过程,可以学习别人的设计思想。
    2020-05-07
    1
  • 南山
    公司在猛抓质量,cr也有足够的重视,自己的松懈也导致了质量的下降。
    亲身经历一个功能的推倒重来到现在的大单体,大部分原因都是自己对重构、质量不够重视,后续反思,矫正,践行!!!
    2020-05-06
    1
  • Frank
    Code Review 除了能对一些代码提出修改建议之外,个人觉得自己能从别人写的代码学到一些好的设计,好的思想。所以自己在平时任务完成的情况下,也会看看别人写的代码,看看他是怎么实现的,如果自己来实现是否有更好的方式等。目前团队中有部分项目代码提交是需要 review 通过才能提交的,在这过程之中,code review 比较侧重的是代码规范,项目中一些特别注意的点,基本上不太可能去充分了解别人的完成的业务,主要是看他能不能讲清楚他写的代码的逻辑。
    2020-05-06
    1
  • 荀麒睿
    看了争哥这篇文章,想了下我们公司,发现就是没有code review的氛围,项目工期动不动就是今天要改完,明天领导就要看,代码也都是五花八门,有些临时写的代码后期也就得过且过,全都已经自由惯了。之前架构师还在推荐进行code review,但是还是很难执行。不过我个人认为,code review是有必要的,这样形成一个好的技术氛围,大家一起成长的感觉很是不错
    2020-05-06
    1
  • do it
    当前有的项目有CodeReview,不过基本都是检查下编码规范。
    2020-05-06
    1
  • 守拙
    课堂讨论:
        
        个人对于Code Review的看法是正面的, CR能有效维持(maintain)项目代码可维护性, 提升团队凝聚力, 老师说良好的CR能降低团队离职率是不无道理的.

        由于本人团队无CodeReview流程, 就只能自己给自己CodeReview了. 践行CR+持续重构可以让自己有收获, 同时也是对公司, 对自己的负责.
    2020-05-06
    1
  • jinjunzhu
    我觉得Code Review还是非常有必要的,不光是一些工作时间不长的同事,即使工作10多年的同事,写出的代码都可能会有一些改进之处,code review也是大家交流技术的机会
    目前的公司没有严格的code review流程,这个很难快速形成,只能慢慢来先养成习惯,之后形成文化
    2020-05-06
    1
收起评论
25
返回
顶部