• 代码重构:解读重构概念及重构实战


    目录

    一.重构是什么(what)

    1.重构的本质

    2.重构≠性能优化

    二.重构的目的(why)

    1.去写好的代码

    2.去写更灵活的代码

    三.重构的时机(when and where)

    1.何时重构

    2.何时不重构

    四.重构的方法(how)

    1.重构关键核心

    2.重构方法

    3.重构工具

    小结


    一.重构是什么(what)

    重构(refactoring):在不改变代码外在行为的前提下,对代码作出修改,以改进程序的内部结构。

    1.重构的本质

    本质上说,重构就是在代码写好之后改进他的设计

    传统开发过程中是先设计,再开发,更像是瀑布开发模式。

    对重构来说,更像是敏捷开发模式,是一个设计与开发小步迭代,不断持续优化的过程。

    2.重构≠性能优化

    相似之处:

    1. 二者都需要修改代码;
    2. 二者都不会改变程序整体功能。

    差异之处:

    1. 重构目的是让代码更容易理解和便于修改,重构后程序可能会运行的更快或者更慢;
    2. 性能优化只关心程序运行的更快,不关心代码的结构和可读性问题。

    二.重构的目的(why)

    目的:改善代码质量。

    1.去写好的代码

    什么是好的代码?

    代码质量优劣并无绝对的判断标准,但是会有一些行业共同认可的标准。因为对于计算机来说,只要代码能运行,编译器不会在乎代码好不好看。但是代码是在实际开发应用中会涉及到修改,交接,是要给程序员和Leader去阅读的,一旦涉及到人,就会出现了代码的可读性问题。

    好的代码的检验标准就是人们是否能轻而易举地修改它。

    好代码应该直截了当,有人需要修改代码时,应该能轻而易举的找到修改点,应该能更快速做出修改,而不引入其他错误。

    傻瓜都能写出计算机可以理解的代码,唯有能写出人类容易理解的代码,才是优秀的程序员。

    让自己的代码更健康,而不是更完美

    2.去写更灵活的代码

    谁也无法预测未来的事。

    对于一个团队来说,应对未来的发展,以及团队人员的变更,或者领导有了新的想法,每当遇到如此事件,我们的代码就要遭罪了。

    灵活性可以更变通的应对不可预知的问题。

    重构后的代码结构会更清晰,可以考虑预留一些功能接口,这样等到一个新同事拿到项目工程时,他会感谢上一位老哥的。


    三.重构的时机(when and where)

    1.何时重构

    两种情况:开发过程中和开发完成后

    • 重构的最佳时机就是在添加新功能之前。

    最常遇到的情况是,待添加的新的功能也会用到之前使用的代码和数据结构,为了避免大量代码复制粘贴,消除重复代码,所以不要一直埋头苦干,而是要停下来多思考。

    重构和添加新功能不能同时进行?

    添加新功能时,就不应该修改既有代码,只管添加新功能;重构时就不再添加新功能,只管调整代码结构。同时进行二者会很混乱。

    • 当代码读起来不明就里时

    一旦需要思考“这段代码到底在做什么”,就要自问一下,“能不能重构这段代码,令其一目了然”。

    • 有更合适的优化空间

    此时代码可能能够被理解,但是写的很复杂或者有更好的优化,这种情况可以参考一些常见的优化方法,以及需要根据长期的开发项目经验来实施。

    • 在开发项目管理中约定重构时机

    通常在较为严谨的项目中,每一步都有自己的流程和时间限制,那么可以在项目管理中提前设置一些重构节点,有计划的安排重构工作,或者专门安排团队来做,定期的code review也是一个共同讨论重构的好时机。

    2.何时不重构

    不是所有情况都需要重构的,没必要为了重构而重构,以下情况就可以不考虑重构。

    • 如果代码本身设计合理,质量过关,维护成本低,团队有着一套很稳定的管理流程,那么只要保持这样的状态就好,按照规则做好自己的事;

    • 如果代码太烂了,并且耦合程度太高,重构的成本>重写的成本,那么考虑升版代码,推倒重新设计;

    • 如果代码本身已经运行了很多年,虽然凌乱,但是不影响运行,可以考虑把一些凌乱的代码打包隐藏到一个API中,以后不用管他即可;

    重构的时机在实际工作中,要取决于整个项目的安排,或者对后续维护运行的影响,以及重构工作的人力成本和时间成本。从大领导的角度来说,通常只会关心交付的内容能不能满足合同要求,能不能结项结款。但是实际上从维护公司长期发展和培养个人程序开发优良喜欢来说,重构是领导层和基层人员都要时刻去考虑的。


    四.重构的方法(how)

    1.重构关键核心

    开展高效有序的重构,关键心得是:小步快跑,保持代码处于永远可以工作的状态,小步修改积累起来也能大大改善系统的设计。

    小步快跑:无论每次重构多么简单,重构后立刻运行测试,修改完成后提交版本控制,便于回滚。

    2.重构方法

    这部分内容是针对实际代码如何修改的实践方法,内容比较多,我会持续更新并通过单独链接的方式呈现,参考书中的js代码,我会做改成C++或者Python来重现,请根据需要自行跳转查看

    3.重构工具

    重构除了我们手动的修改代码,例如使用查找/替换方式去修改名字,目前的IDE中都自带一些自动化重构工具,比如JetBrains的IntelliJ IDEA,还有Eclipse,或者是微软的Visual Studio,都或多或少具备重构功能,有了这些工具我们可以更好的更方便的进行重构,但是重构的思路还是要人来自己设计和掌握。


    小结

    “重构的意义不在于把代码打磨的闪闪发光,而是纯粹的要从经济角度考量”

    对于软件开发工作者来说,重构在实际工作中是由经济利益驱动的,如果只是做一锤子买卖,没人愿意去干重构这件事;或者本身不是你写的代码,你的领导突然让你把他重构,又不会额外给你什么好处;只有在跟你涉及利益相关时,比如你写的代码你后面还要维护它,或者你的团队在开发时就要求了一些管理流程,或者代码由多人协作,每个人都要清理出自己的接口,以防别人代码影响自己。

    在学习或科研中也是一样的,代码更重要的是得到数据结果或者分析结果,你的论文中不会粘贴大量的代码。

    所以不同的岗位,不同的情况,所要进行重构工作这件事的考量不同,但是重构也是一种习惯和素养,如果他成为你开发的一种良好习惯,你总有一天会从中受益的,毕竟谁都喜欢和能写出这样代码的人打交道,养成习惯,学到手,用不用,在哪里用,到时候再说。

    参考书籍:

    《重构:改善既有代码的设计(第2版)》

    该文是参考了上面的内容,是一篇读书笔记及总结感悟,该书的参考语言是JavaScript,作者会用代码案例贯穿讲解,会涉及一些语法上的优化,有JS基础知识会更好理解。

    本文不得用以任何商业活动,仅供学习使用

  • 相关阅读:
    【Java小项目】--- 飞机大战(源码+注释)
    基于预训练模型的Unet【超级简单】【懒人版】【Pytorch版】
    虚幻5框架GamePlay全图
    解决sass问题:npm ERR! node-sass@9.0.0 postinstall: `node scripts/build.js`
    Spring Boot 异步线程静态获取request对象为空 RequestContextHolder 为空 Java 异步线程获取request为空
    项目可交付成果的质量管理该怎么做?
    Thread类的基本用法
    npm run build小技巧
    vuepress 打包 :window is not defined
    3.线性代数-矩阵
  • 原文地址:https://blog.csdn.net/qq_35902025/article/details/139823603