内容简介::notebook: 本文已归档到:「第一次读《重构:改善既有代码的设计》时,我曾整理过一个简单的笔记。最近,因为参与一个重构项目,再一次温习了《重构:改善既有代码的设计》。过程中,萌发了认真总结、整理重构方法的冲动,于是有了这系列文字。代码的坏味道还有几篇没有完稿,后面我会陆续补充。。。
:notebook: 本文已归档到:「 blog 」
第一次读《重构:改善既有代码的设计》时,我曾整理过一个简单的笔记。最近,因为参与一个重构项目,再一次温习了《重构:改善既有代码的设计》。过程中,萌发了认真总结、整理重构方法的冲动,于是有了这系列文字。
代码的坏味道还有几篇没有完稿,后面我会陆续补充。。。
症与药
对代码的坏味道的思考
“有病要早治,不要放弃治疗”。多么朴素的道理 ,人人都懂。
病,就是不健康。
人有病,可以通过打针、吃药、做手术来进行治疗。
如果把代码的坏味道(代码质量问题)比作病症,那么重构就是治疗代码的坏味道的药。
个人认为,在重构这件事上,也可以应用治病的道理:
-
防病于未然。—— 春秋战国时期的一代名医扁鹊,曾经有个很著名的医学主张: 防病于未然 。 我觉得这个道理应用于软件代码的重构亦然。编程前要有合理的设计、编程时要有良好的编程风格,尽量减少问题。从这个层面上说,了解代码的坏味道,不仅仅是为了发现问题、解决问题。更重要的作用是:指导我们在编程过程中有意识的去规避这些问题。
-
小病不医,易得大病。—— 刘备说过:“勿以善小而不为,勿以恶小而为之”。发现问题就及时修改,代码质量自然容易进入良性循环;反之,亦然。要重视积累的力量,别总以为代码出现点小问题,那都不是事儿。
-
对症下药。—— 程序出现了问题,要分析出问题的根本,有针对性的制定合理的重构方案。大家都知道吃错药的后果,同样的, 瞎改还不如不改 。
-
忌猛药—— 医病用猛药容易产生副作用。换一句俗语:步子大了容易扯着蛋。重构如果大刀阔斧的干,那你就要有随时可能扑街的心理准备。推倒重来不是重构,而是重写。重构应该是循序渐进,步步为营的过程。当你发现重写代码比重构代码更简单,往往说明你早就该重构了。
重构的原则
前面把代码质量问题比作病症,而把重构比作药。这里,我们再进一步讨论一下重构的原则。
何谓重构(What)
重构(Refactoring)
的常见定义是:不改变软件系统外部行为的前提下,改善它的内部结构。
个人觉得这个定义有点生涩。不妨理解为:重构是给代码治病的行为。而代码有病是指代码的质量(可靠性、安全性、可复用性、可维护性)和性能有问题。
重构的目的是为了提高代码的质量和性能。
注:功能不全或者不正确,那是残疾代码。就像治病治不了残疾,重构也解决不了功能问题。
为何重构(Why)
翻翻书,上网搜一下,谈到重构的理由大体相同:
- 重构改进软件设计
- 重构使软件更容易理解
- 重构帮助找到 bug
- 重构提高编程速度
总之就是, 重构可以提高代码质量 。
何时重构(When)
关于何时重构,我先引用一下 重构并非难在如何做,而是难在何时开始做 一文的观点。
对于一个高速发展的公司来说,停止业务开发,专门来做重构项目, 从来就不是一个可接受的选项 ,“边开飞机边换引擎”才是这种公司想要的。
我们不妨来衡量一下重构的成本和收益。
-
重构的成本
重构是有成本的,费时费力(时间、人力)不说,还有可能会使本来正常运行的程序出错。所以,很多人都抱着“不求有功,但求无过”的心理得过且过。
还有一种成本:重构使用较新且较为复杂的技术,学习曲线不平滑,团队成员技术切换困难,短期内开发效率可能不升反降。
但是,如果一直放任代码腐朽下去,技术债务会越来越沉重。当代码最终快要跑不动时,架构师们往往还是不得不使用激进的手段来治疗代码的顽疾。但是,这个过程通常都是非常痛苦的,而且有着很高的失败风险。
-
重构的收益
重构的收益是提高代码的质量和性能,并提高未来的开发效率。但是,应当看到,重构往往并不能在短期内带来实际的效益,或者很难直观看出效益。而对于一个企业来说,没有什么比效益更重要。换句话说,没有实际效益的事,通常也没有价值。很多领导,尤其是非技术方向的领导,并不关心你应用了什么新技术,让代码变得多么优雅等等。
-
重构的合适时机
从以上来看,重构实在是个吃力不讨好的事情。
于是,很多人屈服于万恶的 KPI 和要命的 deadline,一边吐槽着以前的代码是垃圾,一边自己也在造垃圾。
但是,**重构本应该是个渐进式的过程,不是只有伤筋动骨的改造才叫重构。**如果非要等到代码已经烂到病入膏肓,再使用激进方式来重构,那必然是困难重重,风险极高。
《重构》书中提到的重构时机应该在添加功能、修复功能、审查代码时,不建议专门抽出时间专门做重构项目。
我认为,其思想就是指: 重构应该是在开发过程中实时的、渐进的演化过程。
-
重构的不恰当时机
但是,这里我也要强调一下: 不是所有软件开发过程都一定要重构。
较能 凸显重构价值的场景 是:代码规模较大、生命周期还较长、承担了较多责任、有一个较大(且较不稳定,人员流动频繁)团队在其上工作的单一代码库。
与之相反,有一些场景的重构价值就很小:
- 代码库生命周期快要走到尾声,开发逐渐减少,以维护为主。
- 代码库当前版本马上要发布了,这时重构无疑是给自己找麻烦。
- 重构代价过于沉重:重构后功能的正确性、稳定性难以保障;技术过于超前,团队成员技术迁移难度太大。
如何重构(How)
重构行为在我看来,也是可以分层级的。由高到低,越高层级难度越大:
-
服务、数据库 现代软件往往业务复杂、庞大。使用微服务、数据迁移来拆分业务,降低业务复杂度成为了主流。但是,这些技术的测试、部署复杂,技术难度很高。
-
组件、模块、框架 组件、模块、框架的重构,主要是针对代码的设计问题。解决的是代码的整体结构问题。需要对框架、 设计模式 、分布式、并发等等有足够的了解。
-
类、接口、函数、字段 《重构》一书提到了**“代码的坏味道”**以及相关的重构方法。这些都是对类、接口、函数、字段级别代码的重构手段。由于这一级别的重构方法较为简单,所以可操作性较强。具体细节可以阅读《代码的坏味道》篇章。
前两种层级的重构已经涉及到架构层面,影响较大,难度较高,如果功力不够不要轻易变动。由于这两个层级涉及领域较广,这里不做论述。
此处为分割线。下面是代码的坏味道系列。。。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 代码坏味道之滥用面向对象
- 代码坏味道之非必要的
- 影响您的代码库的10个编程代码味道
- Ubuntu 18.04 默认壁纸已提供下载:还是熟悉的味道
- Java无可匹敌的变身装备,钢铁侠客的绝密味道
- Java 无可匹敌的变身装备,钢铁侠客的绝密味道
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
区块链:定义未来金融与经济新格局
张健 / 机械工业出版社 / 2016-6-18 / 49.00
从构建价值互联网的角度看,区块链的出现意味着从0到1。正因如此,本书章节结构与常见的体例不同,从第0章开始。第0章从文字与货币的起源出发,通过论述人类信息传递和价值传输手段的进步,说明区块链技术诞生的必然性。第1章用深入浅出的语言讲解区块链的本质、运行原理、颠覆性潜力以及区块链技术的现状与未来;第2章宏观讲述了区块链技术带来的新产品和新机遇,包括数字货币、互联网金融、物联网,以及新一代的基础设施;......一起来看看 《区块链:定义未来金融与经济新格局》 这本书的介绍吧!