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

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

王争 2020-05-04
我们知道,项目越复杂、代码量越多、参与开发人员越多、开发维护时间越长,我们就越是要重视代码质量。代码质量下降会导致项目研发困难重重,比如:开发效率低,招了很多人,天天加班,出活却不多;线上 bug 频发,查找 bug 困难,领导发飙,中层束手无策,工程师抱怨不断。
导致代码质量不高的原因有很多,比如:代码无注释,无文档,命名差,层次结构不清晰,调用关系混乱,到处 hardcode,充斥着各种临时解决方案等等。那怎么才能时刻保证代码质量呢?当然,首要的是团队技术素质要过硬,能够适当地利用设计原则、思想、模式编写高质量的代码。除此之外,还有一些外在的方法可循。
今天,我就从研发管理和开发技巧的角度来带你看下,面对大型复杂项目的开发,如何长期保证代码质量,让代码长期可维护。
话不多说,让我们正式开始今天的学习吧!

1. 吹毛求疵般地执行编码规范

严格执行代码规范,可以使一个项目乃至整个公司的代码具有完全统一的风格,就像同一个人编写的。而且,命名良好的变量、函数、类和注释,也可以提高代码的可读性。编码规范不难掌握,关键是要严格执行。在 Code Review 时,我们一定要严格要求,看到不符合规范的代码,一定要指出并要求修改。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《设计模式之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(19)

  • 守拙
    课堂讨论:

    保持代码质量的经验:

    1. svn/git 少量多次提交, 写清晰的commit: 有助于版本管理/bug追踪/code review.

    2. 前后端业务命名统一: 没啥说的, 前端头像叫avatar, 后端叫face_icon就很别扭.

    3. 适当的工作节奏: 小团队难免遇到加急的任务, 每天大十几小时的实际编码工作让人无暇考虑什么规范, 优雅, 可读性可维护性...心里只想去tm的.(既然老板不想好好用我的技能, 那我就一路平A呗.)

    4. 良好的工作氛围: 技术/产品/设计/运维/市场都是无产阶级, 屁股要坐端正了, 要搞清楚谁是战友谁是阶级敌人, 非暴力沟通, 不要甩锅/埋怨/为难对方. 大家工作的开心才是硬道理, 开心的重要性远远高于规范/流程/制度等等. 当然不是说每天傻乐呵, 程序员作为无产阶级单兵作战单位, 要想清楚一件事: 吾辈为何而战? 相信有缘读到这里的各位都有自己的答案. 我的答案是: 为了更好的生活.
    2020-05-05
    26
  • Frank
    从开发技巧来看,我觉得除了文章中提到的哪些点,我们还可以尝试阅读优秀的开源框架,如Spring,Netty等,看看这些优秀的框架是怎么做的,我觉得是能够从中学习到一些东西的。
    2020-05-05
    1
    5
  • 马以
    的确要看人,所以很多招聘还会写,希望招一些对代码有洁癖的人
    2020-05-04
    4
  • J
    代码质量真的最应该负责的人就是开发人员自己,而不应该是质控人员。
    质控人员应该变成另外一种的开发和运维人员,修建部门内的“耻辱墙”,将代码的测试覆盖率、CI的成功率、自动化的代码风格、缺陷扫描结果在部门内及时公开透明。只有知耻而后勇才能创造动力。

    有效且全面的测试用例是重构的重要保障,王争老师提到的持续重构中,有些团队在代码腐朽后直接推倒重来,那是因为团队根本没有信息能够在祖传代码里面重构出来。如果祖传代码有高质量的测试用例,那就能够为持续重构提供安全网,能够使得重构可以持续和零散地进行。五分钟修改一个有坏味道的类才能变得可能,只要测试不通过,就可以马上回滚这5分钟内的修改。
    2020-05-05
    3
  • 辣么大
    之前在的项目组做的是银行的项目,十几人的团队,属于项目维护。项目不紧急,三个月一小版更新,半年一大版。拿到需求的时候首先是分析需求,然后是写开发文档,开发文档组长检查通过后才能开始写代码提交。组长负责merge代码,同时做了code review的工作,觉得小团队这样做还是挺有效的。
    2020-05-04
    3
  • 1.需要二次开发的项目,每个模块都应该包含必要的说明文档
         做过一个媒体项目的二次开发,当项目需要对接新模块时,项目经理会甩给我一个jar包,一套源码,然后我自己研究如何打通模块之间的通讯,沟通补充那些公司内部的依赖,打包模块,部署到某台机器上,这个过程中沟通成本特别大,找人要依赖,找人问业务流程,有的资料老大没给全,得靠自己去猜,劳心费神,有的模块代码实现里还有bug,有的模块的实现细节try-catch把异常吞掉,导致很难发现问题,对接的时候相当吃力,如果在一开始就能提供一个说明文档,简单描述一下模块的业务范围,对接方式,几句话的事就能帮忙解决大部分问题
    2.不论是管理者还是工作者,工作中都不能携带情绪
        我刚工作的时候,什么代码规范都是一头雾水,工作难度又高,一犯错我老大就要开始批评我了,那一阵真是很难受,每天上班都是严阵以待,随时准备跟他打一架的感觉,现在想一想,其实只要大家都不要携带情绪,他以一个过来者的身份指导我,我以一个学习者的身份接受指导,他就能保时保量把项目交付给客户,我也能得到成长
    3.对经典源码的阅读,有助于提升设计水平
         阅读源码的关键点在于掌握设计原则,设计模式的应用,以及某些特殊场景的解决方案.我在项目中遇到一个摄像头的管理模块,一个模块要管理多个摄像头,一个摄像头的方法有建立连接,停止连接,心跳校验等通用的方法,连接后回调方法的的行为各不相同,这让我想起了先前阅读过的tomcat源码,它用到了模板方法模式,用接口定义行为,用抽象类封装具体实现,然后在具体的每个摄像头的bean里实现了不同的回调方法.遵循这个方式,从我拿到需求,到完成这个设计,一共就用了一两个钟头
         在这个模块之后的扩展中,发现很多摄像头有共同的回调行为,而且摄像头的数量经常变动,最好通过配置文件来配置bean.然后我用在专栏学到的工厂模式的代码,不到半天就完成了这部分的重构
    2020-05-07
    2
  • jinjunzhu
    1.待研发团队的leader很重要,如果他要只是一个做管理或者业务的leader,那保持代码质量很难的,甚至技术氛围都不会太好
    2.团队的中高级开发有代码洁癖就好了,可以不断地重构代码,review其他人写的代码
    3.团队成员开发过程中,不能随便提交代码。要建一个自己的分支,提交后做merger request,leader或高级开发在这个过程中进行review后做些修改的comment
    4.不断改善团队的技术氛围,这个很重要
    5.团队成员要熟悉业务,这个也非常重要。尤其是一些专业性强的业务,比如征信系统、信贷核心系统等。熟悉了业务,才能在开发过程中更好地使用设计模式和原则
    2020-05-06
    2
  • javaadu
    我们今年就启动了一系列的措施来保障CR和单测的落地执行:
    1. CR覆盖率
    2. 测试用例注入攻击
    3. CR代码攻击
    2020-05-06
    2
  • Jxin
    1.代码质量这个,目前真的只能落到个人追求。
    2.中高级开发是开发主力。对于中高级开发,就升职加薪来看,技术的效益远高于编码设计能力。设计的好坏,在外行来看终究不也只是翻译了业务逻辑,所以希望他们认可买单挺难的。而烂代码对自己的影响还是比较有限的(自己写的,可读性再差也多少能读懂。扩展性不好导致难改,直接技术实现不了,历史原因,也就过去了)。
    3.所以就两三年的工作来看,是加班重构承担风险。还是下班学习稳步提升呢?
    4.存在既合理,该重视的会在该重视的时间被重视。
    2020-05-04
    2
  • 忆水寒
    经验就是 写出来一堆垃圾代码的人,下次不和他合作了。
    2020-05-04
    2
  • Heaven
    最近就是因为一些新需求的出现,导致接手了一个很久没有人维护的项目,虽然运行起来比较稳定,但是内部充斥着大量的临时解决方案,代码冗余过高,而且没有开发文档,实在是难以维护,只能花费大量的时间去读懂当时的实现思路,然后进行重写一遍,开发效率实在上不去,如果当时的开发人员能够进行一些代码的优化和重构,那么现在相比容易的多了,对于提高代码质量---我个人认为使用多分支管理最为重要
    2020-05-06
    1
  • 不能忍的地精
    公司组织统一的编程规范学习,并进行考试。每个人对代码进行评审,并找出不好的地方进行优化
    2020-05-06
    1
  • 子豪sirius
    code review一开始能正常开展,但往往随着项目进行下去,需求不断变化,工期赶就坚持不下来了
    2020-05-04
    1
  • Jackey
    用一些lint工具来保证codeStyle,在做code review的时候就可以把更多的精力放到代码逻辑和代码设计上了
    2020-05-04
    1
  • 小喵喵
    codeReviewer 是否可以借助一些地方工具来进行是不是更好些呢?
    2020-05-04
    1
  • liu_liu
    在业务开发中,对已有的基础组件或基础设施不要重复造轮子,防止在工程中出现多套类似的代码。尤其是当项目越来越大时,经常会发生这样的情况。

    造成这种问题的原因可能是:

    1. 对基础设施功能不熟悉,不知道已经有这种功能。这就需要基础组维护一份功能文档,并保持更新。并且业务同学也要尽量快速去熟悉项目代码。

    2. 业务同学觉得代码写的很烂或者不能满足需求,想自己重写一套。这时应提需求给基础组进行改造,或者提 pr 给他们,实在不行才考虑自己另写一套。这也是防止工程代码冗余的一种手段。
    2020-05-04
    1
  • Rayjun
    讲大道理谁都会,但是落实到细节上其实就很难了,所以代码规范方面不能够依赖人的主动性,否则肯定无法推行下去。最好的方式就是适用工具来执行,比如适用代码规范插件,没有检测过的代码就无法提交。

    这样依赖,做代码 review 就会轻松很多,只需要关注代码的整体逻辑和实现方式是不是有问题,而不用去关注代码规范。
    2020-05-04
    1
  • 全炸攻城狮
    我们项目的codereview就是虎头蛇尾了。一开始确实是有计划,做成常态化,可是随着项目压力变大,对于这个事情就慢慢忽视了
    2020-05-04
    1
  • 小晏子
    课后思考:文章总结的很全面了,唯一能想到的就是在细化一下,模块拆分清楚后指定每个模块的负责人,然后负责人要严格把控code review,并不断对模块进行重构。
    2020-05-04
收起评论
19
返回
顶部