设计模式之美
王争
前Google工程师,《数据结构与算法之美》专栏作者
立即订阅
18733 人已学习
课程目录
已更新 30 讲 / 共 100 讲
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 | 实战二(下):如何实现一个支持各种统计规则的性能计数器?
设计原则与思想:规范与重构 (1讲)
27 | 理论一:什么情况下要重构?到底重构什么?又该如何重构?
不定期加餐 (2讲)
加餐一 | 用一篇文章带你了解专栏中用到的所有Java语法
加餐二 | 设计模式、重构、编程规范等相关书籍推荐
设计模式之美
登录|注册

27 | 理论一:什么情况下要重构?到底重构什么?又该如何重构?

王争 2020-01-03
“重构”这个词对于大部分工程师来说都不陌生。不过,据我了解,大部分人都只是“听得多做得少”,真正进行过代码重构的人不多,而把持续重构作为开发的一部分的人,就更是少之又少了。
一方面,重构代码对一个工程师能力的要求,要比单纯写代码高得多。重构需要你能洞察出代码存在的坏味道或者设计上的不足,并且能合理、熟练地利用设计思想、原则、模式、编程规范等理论知识解决这些问题。
另一方面,很多工程师对为什么要重构、到底重构什么、什么时候重构、又该如何重构等相关问题理解不深,对重构没有系统性、全局性的认识,面对一堆烂代码,没有重构技巧的指导,只能想到哪改到哪,并不能全面地改善代码质量。
为了让你对重构有个清晰的认识,对于这部分知识的讲解,我安排了六节课的内容,主要包含以下几个方面:
对重构概括性的介绍,包括重构的目的(why)、对象(what)、时机(when)、方法(how);
保证重构不出错的手段,这里我会重点讲解单元测试和代码的可测试性;
不同规模的重构,重点讲解大规模高层次重构(比如系统、模块、代码结构、类与类之间的交互等的重构)和小规模低层次重构(类、函数、变量等的重构)。
话不多说,现在就让我们来学习第一部分内容:重构的目的、对象、时机和方法。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《设计模式之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(51)

  • brianhuuu
    重构最难的还是领导不支持

    作者回复: 😂

    2020-01-03
    3
    45
  • 刘大明
    前段时间刚重构了一个功能模块。该模块可以说是祖传代码。里面堆砌着各种判断条件,就是所谓的箭头型代码。我接手这个功能重构的
    1.把代码读一遍和跑一遍,理解里面的需求。尽量画一个流程图。
    2.建立防护网。将需求拆分之后,针对每个拆分的业务点写单元测试。
    4.开始重构,解耦逻辑,设计方法的时候尽量让职业单一,类与类之间尽量符合迪米特原则,有依赖关系的类尽量只依赖类的特定方法。我觉得比较基础也是比较重要一点。不要有重复代码。命名要规范,类的各个职业要清晰。重构过程中,其实也要时不时的识别代码的坏味道。尽然是重构,那么肯定要比不重构之前肯定要更好。
    5.重构完成之后,通过防护网的测试。

    当天重构代码上线之后,基本上没有问题。运行了几天之后有一小段逻辑隐藏的比较深没有写这个逻辑测试,后面补上了一直都没有出过问题了。还是比较稳定的。
    我这里只是做了中小规模的重构,后面跟着小争哥继续系统的学习大规模重构,以及重构的技巧和思想。
    2020-01-03
    12
  • 失火的夏天
    重构自然是要用的我们牛逼的设计模式和数据结构了。。。啊-_-||开个玩笑哈。

    重构这玩意嘛,其实在第一版提上去的时候就应该要重构了,也就是我们常说的,边写边重构。

    一个方法写的时候发现分支判断太多,工厂模式就要登场了。

    如果大部分代码都比较重复,这个时候就需要往底层的抽象,甚至用上策略模式。

    需要做一个非功能性需求,每一个接口调用都要记录的东西,我们为了避免业务侵入性,就要考虑代理模式重构之前的业务侵入性强的代码,将功能与非功能分离。

    说到底,重构不要等,而是马上动手,只有行动了,才不会害怕。第一版稍微辛苦一些,以后就不会那么恶心了,功在当代,利在千秋。
    2020-01-03
    7
  • 辣么大
    代码中的坏味道,好比人的头疼脑热。“小病”不管的话,迟早会发展成大病,需要动大手术,甚至病入膏肓。
    实际中的一些体会:
    一、在完成一个新需求时,在时间允许的情况下,会经常改进代码,使代码更优雅。
    二、“重构不改变外部的可见行为“,引入自动化测试非常重要,国内有些团队可能做的不好。因为改动代码可能引入bug,如果没有自动化测试,测起来就会非常费劲,改动的结果不确定。如果测试不方便,谁会愿意修改之前work的代码呢?
    三、持续集成、自动化测试、持续重构都是很好的工程实践。即使工作的项目中暂时没有使用,也应该有所了解。
    2020-01-03
    3
    5
  • 1,无单测的条件下,别说重构了,我不想以前任何代码,对,我是一个怕事的程序员~
    2,小步快走的重构方式很重要,毕其功于一役的重构总是构完了,发现和主干代码相差哈哈哈,我还是不合入了吧,留给自己欣赏自己精细雕琢的玩具。。。
    2020-01-03
    3
  • 桂城老托尼
    重构的经验,1.工作中鼓励持续重构,但不赞成为了重构而重构.2.重构一定要在有比较完善的测试用例覆盖和回归用例库的情况下进行(可测试性),否则会相当危险。3. 重构最好有AB工具灰度比对,逐步切流。4. 重构最好有资深的成员共同CR,结合大家的意见,可能本次的重构也会引入一些怪味道。
    重构的教训,出现问题的场景往往在于一个细小的点,能注意到的往往没有问题。 重构一旦出问题会面临比较大的精神压力和信心挑战,会部分挫败重构者的积极性,这时候需要TL的鼓励和支持,避免让员工感受到做多错多。
    2020-01-04
    2
  • 李小四
    设计模式_27

    没有做过大重构,小重构倒是经常做,我发现我做需求常常比别人慢,原因是大概率我改的地方比需求涉及的多一些,可以算是小重构吧。

    很同意王争老师说的,大部分人都没有进行过重构,而大部分的代码又是由这大部分的人写的,所以,市面上的大部分代码可能都。。。

    我在创业公司呆过,见识过技术总监申请重构时被挑战的体无完肤,不欢而散,代码一直烂下去,最终谁也改不动,大量的客户流失,业务严重受损。当然,我在这个过程中,毫无作为。。。
    2020-01-03
    2
  • 再见孙悟空
    庆幸自己有个好领导,日常对我的代码 review 得非常严格,平时使用 source tree ,git rebase 可以清晰地看到每一次提交,这样代码 review 起来就没什么压力了。

    另一方面,最好在项目的开始阶段和大家分享你的设计思路,否则等项目要准备发布上线时,拉上一堆人来 review 代码时,其实效果几乎没啥的,大家只能看看命名风格,像什么高内聚低耦合,设计模式,封装抽象等即使有问题,也会因为项目时间紧而将就放行。
    2020-01-03
    1
  • Calvin
    在农村长大的孩子应该多少见过盖房子的情形,一般师傅会用砖挂一根线在不断的盖房子的过程中观察整个房子是否出现歪斜的情况,这个过程是持续的,要时刻保证一砖一瓦的建上去的房子是笔直的。写代码就是如此,团队应该有这样的"一根线"来保证产品的正常开发,不至于整个项目出现问题,而重构就像是发现了房子有点歪需要重新进行改正,高手是发现绳子偏移的时候就开始纠错了,大部分团队只能等到明显发现房子歪了才开始修正。
    2020-01-03
    1
  • 安静的boy
    我现在负责的项目是我从零就参与的,到现在大大小小已经迭代了十几个版本。我发现随着版本的迭代,会出现很多相似的重复代码,这个时候我就会去想办法重构代码,做一些抽象啊,利用一些设计模式,不过我现在只用到了模板设计模式。如果不重构我觉着以后需求再变化改动的地方太多了,而且还很有可能出错。另外,我发现重构了以后代码的可读性也会比较好。
    2020-01-03
    1
  • 阿卡牛
    品味很重要,能品味出代码的味道
    2020-01-03
    1
  • 黄林晴
    打卡✔
    心得体会吧,哈哈哈哈哈
    我被频繁改动的需求压的喘不过气,再牛逼的架构怕是也抵不住😒
    2020-01-03
    1
    1
  • Jackie
    终于把落下的课都不上来了,后面要实时跟进老师的脚步了。

    重构的意义还是很大,有重构的习惯对于自己提升技术实力很重要,有些看似在存在面试题里面的设计模式完全可以在重构的时候派上用场。

    同时,部门有重构的习惯,也会形成比较好的技术氛围。看到好味道的代码,大家都会争相效仿,不会也不好意思在整洁的代码丢下“老鼠屎”。反之,看到坏味道的代码,大家就有可能群体性破罐子破摔。
    2020-01-05
  • 奔跑的小孩
    1.要具有重构意识,阶段性重构代码,重构分为大重构(模块重新划分、类与类之间关系重构等)和小重构(通过设计模式或者代码优化程序等 )
    2.重构情况下最好不要改变外部的代码调用规则,兼容之前的代码
    3.小跑试错,快速迭代,不要上来就是大而全的迭代
    2020-01-05
  • Frank
    以前在写代码时只偏重于代码是否能跑通,而对代码质量关心的比较少。而团队没有强调这种意识,即时有,给出的概念也比较抽象,很难落地。比较幸运的是换了好的平台,解除到了更多的东西,这些东西自己也在慢慢接触。知道了除了写代码之外,还要思考如何写出“好代码”。持续重构是一个在实际开发中不断提升代码质量的好方法。体会最深的应该是在前1个月自己从零开发的一个模块中就使用到了这种方式来提升代码质量(主要是提高可维护性,可读性)。当时有个类代码写的很多,逻辑很复杂。大约超过了1000了,写了很多大函数(其实在一开始就应该尽量避免写大函数),在实现完基本功能后,一有时间,自己就重新去读自己写的代码,看到不好的地方(如命名规范,超大函数等)就进行修改,重构。通过这样的实践,深刻体会到了“时刻具有持续重构意识,才能避免开发初期就过度设计,避免代码维护的过程中质量的下降”。
    2020-01-05
  • L🚲🐱
    如楼上所说 重构最大问题是领导不支持,做的政府项目, 要求稳定就行,代码质量差的不行,很无奈😂
    2020-01-05
  • yang
    事实上对代码的平时的优化与改进还好,大的重构要考虑清楚,目标是什么。这个目标不好把。是提升了多少稳定性?交付效率?还是提升了连接效率?要考虑清楚,否则投入很多人力,重构完成,也不一定是没有bug,还有很多技术的重构最好和产品的重构一起。如果是小的技术功能改进,好的办法是ab测试,慢点切流量.
    2020-01-05
  • 荀麒睿
    就拿我们公司的系统来说,之前两个团队开发整合,就是因为没有进行好的规范,并且没有进行持续重构,再加上人员的走动,导致之后的人在接手的时候碰到新的需求,也不知道是否有可复用的代码,就直接再写新的接口,最终导致整个系统变得异常笨重,重复的接口越来越多。后来因为要迁移部署环境,进行了一次大型的重构,公司安排了新来的员工来负责,结果业务不熟悉,也就只能按照新部署要求,做了一些简单的调整,代码依旧越来越复杂,所以我觉得持续重构的意识真的很重要,看了争哥的专栏之后,赶紧对以前的代码重新再优化一遍
    2020-01-04
  • 张迪
    现在我们代码乱的一塌糊涂,这个项目是后来接手的,项目开发人员变了好几轮,里面堆得一大堆代码。现在做个设计改动,得动用一个团队的力量一个月的时间
    2020-01-04
  • leon
    新入职某大厂的时候做了一次大规模重构,把一个核心系统的逻辑迁移到另一个系统。最大的困难是 1. 看不懂代码,到处if else , 代码层次混乱,业务逻辑复杂。 2. 没有单元测试,没有检验重构正确与否的标准。做了2个月,十分痛苦。

    抱怨一下,ppt写的一个比一个好,代码写的一个比一个烂
    2020-01-04
收起评论
51
返回
顶部