聊一聊为什么不重构呢?

开发 开发工具
重构是提高质量的重要工具。许多开发方法都依赖于重构,尤其是对于敏捷方法,在更多计划驱动的组织中也是如此。但事实上,是否以重构来处理设计中的某些问题呢?是否存在重构的障碍呢?

[[442713]]

重构是提高质量的重要工具。许多开发方法都依赖于重构,尤其是对于敏捷方法,在更多计划驱动的组织中也是如此。但事实上,是否以重构来处理设计中的某些问题呢?是否存在重构的障碍呢?

不重构的原因

存在质量问题而不进行重构的理由可以分为以下几类:

资源

对所需资源的关注是不进行重构的一个经常被提到的原因。最常提到的资源是时间,比如“DDL不允许”,“有时候就是没有时间”或者单纯的“就是没有时间”。

风险

同样经常被提到的还有更改所涉及的风险,尤其是引入新的错误或其他问题,比如“这种重构很耗时间,而且引入错误的风险很大”,以及“反正还能用,管它干嘛”等等。

难度

另一个问题是进行更改的难度,比如“继承很难正确重构”和“这种重构通常很困难”等等。

投资回报率

虽然重构可能会带来好处,但也有成本,投资回报率也必须考虑,例如“必须再次权衡成本和好处,在承担重构、重测试等方面的成本之前,必须明确收益。”

技术

项目的特点限制了重构的能力。例如,必须实现超出限制的第三方接口,担心任何潜在的更改对系统其他部分的影响,对代码的熟悉程度,处理遗留代码,以及缺乏其他支持(如测试套件) ,尤其是“大量遗留代码库使重构变得困难”; “如果没有测试方法,系统可能被破坏”; 以及“没有时间进行重构的预算。”等等

管理

开发者并不总是能控制他们的时间使用。老板或客户更有发言权,比如“想要重构,但老板不喜欢”、“只关注截止日期的老板”、“客户不会为此付钱”等等。

工具

工具支持不足也被认为是不重构的一个原因,然而,这些的工具并不是那些进行重构的那些工具,某些重构非常痛苦,实际上是缺乏工具的支持。微软对 Windows 进行了某种形式的重构,确定了执行重构的挑战,例如管理组件间和分支间的依赖关系以及维护向下兼容,也许最令人惊讶的主题是完全不关心重构工具支持的存在和质量。

重构的障碍与时机

重构并非难在怎么做,而是难在何时开始做。对于一个高速发展的企业来说,停下来做重构从来就不是一个可接受的选项,“边开飞机边换引擎”才是公司想要的。当代码还不是很混乱的时候,重构的必要性不高,相比不小心重构出错导致熄火的风险来说,得过且过可能反而是一个明智之选。于是,各种技术债就这样慢慢积累起来,直到业务因为各种技术债快跑不动的时候,才不得不用一些激进的重构手段快速的解决历史顽疾。

代码分析未必有效

在软件工程中,往往使用每类加权方法(WMC)和继承树(Depth of Inheritance Tree,DIT) 来度量面向对象的设计,这些度量常常被表示为可能的设计问题,即WMC 或 DIT 的值越高,就越有可能出现问题。WMC 是类的大小度量的一种形式,最简单的形式是类中方法数量的计数。DIT 捕获继承层次结构的一个特征,它是从类到层次结构根的最长路径长度。然而,对软件系统的测量表明,有些类具有很多方法,或者在层次结构中非常深。它就需要重构么?

实际上,工程师更倾向于限制类的深度,而不是方法的数量,但是当超过某个深度限制时,开发者倾向于不做任何事情。

两个主要障碍

很多时候,无法确定 ROI 才是一个障碍,比如“如果不能对需要多长时间做出合理的估计,就不会管它。”也就是说,决定不重构并不是因为它被认为是一个坏主意,而是因为它的收益不确定。在特定情况下进行重构时,通常很少或根本不知道实际的 ROI 是什么。

一个潜在的障碍是很难将重构目标转化为重构操作。需要的是一个决策支持系统,使从业人员能够量化长期和短期效益。这将有助于为决定所需资源是否合理或是否容忍潜在风险提供信息,还允许开发人员和管理人员就是否重构做出明智的选择。

重构的时机

具体地,Martin Folwer在《重构》一书中提到,需要识别坏味道,并提出了进行重构的4种情况,即关于重构的CRUD:

  • 增:增加新功能的时候,发现需要重构来便于新功能的添加
  • 删:事不过三,消除重复
  • 改:修复缺陷,改Bug的时候
  • 查:代码评审的时候得到了很多建设性的意见

也就是说,设计没有表达出对需求的最新理解,或者需求没有被很好地实现,而且已经发现更好的实现方法,以及发现了一个能使某个设计变得简单、灵活的方法。实际上,重构的时机只是做出是否重构的判断时机。

另外,使用重构工具的两个好处是错误率更低,所需时间更少,因此好的工具支持应该在一定程度上解决开发人员的问题。只有当重构的决定已经做出时,重构工具的支持才会起作用。实际上,不使用自动化进行重构的原因可能包括信任、可预测性和复杂性。

小结

无论软件设计质量问题是如何识别的,开发者都无法通过重构来根本消除这些问题。减少甚至消除重构的障碍有可能显著提高软件质量。一种方法是提供目标导向的重构支持,而不是操作导向的重构支持。另一个办法是更好地量化效益,从而更好地告知是否重构的决定。

责任编辑:武晓燕 来源: 51CTO专栏
相关推荐

2021-08-26 05:01:40

0x3f 数组算法

2022-01-28 08:47:25

软件系统重构

2022-11-09 08:05:15

JavaScriptsuper()

2018-06-07 13:17:12

契约测试单元测试API测试

2023-09-22 17:36:37

2020-05-22 08:16:07

PONGPONXG-PON

2021-01-28 22:31:33

分组密码算法

2020-06-28 09:30:37

Linux内存操作系统

2022-10-08 11:33:56

边缘计算云计算

2022-03-08 16:10:38

Redis事务机制

2018-01-10 14:13:04

测试矩阵API测试

2022-11-26 00:00:06

装饰者模式Component

2020-08-12 08:34:16

开发安全We

2021-01-01 09:01:05

前端组件化设计

2020-09-08 06:54:29

Java Gradle语言

2022-03-29 09:56:21

游戏版本运营

2019-12-17 10:06:18

CDMA高通4G

2022-08-08 08:25:21

Javajar 文件

2021-01-29 08:32:21

数据结构数组

2021-08-04 09:32:05

Typescript 技巧Partial
点赞
收藏

51CTO技术栈公众号