随着时间的推移, 一个大型项目的代码会变得越来越糟. 我希望幸运地能找到例外, 但总体来说在大多数的项目中是如此. 原因很明显:
-
越来越多的特性. 这导致复杂度的增加.
-
捷径和权宜之计. 为了支持类似“我们在八月份需要这个花哨的搜索,没问题!(We need this fancy search till August. Period!)”的特性.
-
开发人员的轮换 新的开发人员并不知道所有架构背后的基本决定和想法. 知识也不可避免地随着人员的轮换而丢失。
-
开发团队的扩大 越来越多的人- 越来越少的沟通 – 坏的决定. 这导致代码重复, 和一些在缺乏基本条件的深刻理解等运行的hack代码
突然你不能很容易地添加新的功能,你不能轻易做出重大调整,你有沉重的技术负债,开发团队濒临崩溃。 你想改变这一点,只有两个选择:重构或一切从头开始重写。
间断平衡是一个生物学理论,但它也被应用到其他复杂的自适应系统,像社会等。它指出,在相当长一段时期内系统几乎没有变化,然后非常迅速地变化。接着再次获得平衡。听起来很耳熟? 是的,重构几乎是相同的过程。
任何对系统的改变在短时间内都会引入混乱。重构的目的的目标就是要消除混乱,但在刚开始时通常会加重混乱。当你正工作于改变时,你会让系统不是很稳定。但一旦改变结束系统就会更加有序。对于软件开发来说,这一条不总是对的。如果你使用了分支,会使改变更加安全。重大的改变也增加了引用新bug的风险。
重构真正的危险是局部最优(local optimums)。比起重构,完全重写你可以得到更好的架构。那怎么办呢?如果你有一个最终架构构想,利用它,试着做一个从当前的架构的到新架构的路线图。通常对简单的部分应该摆脱重构。
当你从头开始重写时,不可避免会带了混乱,其中绝大部分很难预测最终结果。同样你有一个新的奇点(singularity),将开创新的产品纪元。然而,你能确保会比以前的更好吗?在新产品版本中你要修复多少相同的bugs?
然而,重写也许看起来很快。我的意思是说你可以通过重写很快的发布一个新的版本,但多数是带有更多的bugs并且是不稳定的。
我认为我们可以预期到:
绿线显示了在重构中混乱的变化。每次重构后混乱的会有少量增加,但随着系统变得稳定混乱也减少了。你会很晚才看到的最终版本,但请记住,在这之前的多次版本发布会让客户较早地获得好处。
黑线是在全面重写中混乱如何变化。在重写时,旧系统还在那时,混乱没有变化。但公开发行后,混乱大幅度增加。可以想像不少新(老)bugs和怪异问题会出现,因此稳定期会更长 。但是,发布频率也会更快,原因是没有后顾之忧。例如,当你改变某个地方时你不需要支持所有的地方。但在重构时,需要保持系统在任何时候都是工作且稳定的,这就需要更多额外的工作量。
可以从另一个角度来看这个问题。重构是适应,而全面重写是革命。同样,革命是一个混乱的猛兽。你可以选择慢慢地调整产品以适应新的外部条件下,或作一次革命重写。
我觉得没有普遍正确答案来回答这个问题。如果面市时间非常重要,并且新版本在6个月内不能发布的话你会失去很多业务,您可以尝试完全重写。但是要充分考虑副作用!因为质量可能明显下降和需要很长时间达到稳定,这些都有可能损害现有的客户。
在大多数情况下重构是可取的。循序渐进,高品质,不断改进,满意的客户。我更喜欢它。但重写是如此的充满诱惑...
查看英文原文:Refactoring vs. Rewrite by Michael Dubakov
- 大小: 5.2 KB
分享到:
相关推荐
- 重构与重写的区别 - 何时进行重构 2. **重构的基本原则** - 代码可读性 - 减少重复代码 - 提高模块化 3. **常见的重构技巧** - 提取方法(Extract Method) - 移动功能(Move Function) - 替换算法...
#### 重写与覆盖的应用示例: 考虑以下代码片段: ```csharp public class ParentClass { public virtual void VirtualMethod() { Console.WriteLine("ParentClass's VirtualMethod"); } } public class ...
这是重构与重写代码最本质的区别。重写是彻底抛弃旧代码,而重构是在原有代码的基础上,通过小步骤、有计划的更改,逐步提高代码质量。 在重构实践中,读者还可以参考其他一些重构相关的书籍和资源。比如John Brant...
针对这个需求,"TabContraol重构-vb2010重写TabControl控件的使用TabControl竖向显示.rar"压缩包提供了三种不同的方法来实现这一功能。 1. **方法一:自定义控件绘制** 这种方法涉及重写`TabControl`的绘制逻辑。...
C#重写MessageBox对话框C#重写MessageBox对话框C#重写MessageBox对话框C#重写MessageBox对话框C#重写MessageBox对话框C#重写MessageBox对话框C#重写MessageBox对话框
- **内容重构与重写**:新版完全重新组织和重写了内容,重点突出现代C++编程风格。 - **标准库的应用**:新版更加重视标准库的使用,较早引入标准库概念,并利用库功能改进示例。 - **语言主题顺序调整**:语言主题...
Martin Fowler所著的《重构:改善既有代码的设计》是一本深入探讨重构技术的经典著作,它与《设计模式》齐名,为软件开发人员提供了超过70种行之有效的重构方法。本书的目标是教会读者如何识别代码中需要重构的部分...
- **大重构**:指对项目进行大规模的重构,可能涉及整个模块的重写、架构的替换甚至是编程语言的变更。 - **案例分析**:以Zope2到Zope3的迁移为例,探讨了为何进行大重构以及其过程中遇到的问题。 - **背景**:...
【描述】:“精品--本人精品课程毕业设计的重构,使用springboot框架重写”进一步强调,这个项目是对原有毕业设计的优化与改进,采用Spring Boot进行重写。重构通常是为了提高代码质量、可读性和维护性,同时也可能...
重构是提高代码质量、可读性和维护性的重要手段,通过对现有代码进行一系列微小而安全的改进,而不是一次大规模的重写,来提升软件的结构。 中文版和英文版的《重构》都包含了大量的实例和实践指导,旨在帮助软件...
【标题】"本人精品课程毕业设计的重构,使用springboot框架重写.zip" 提供了主要的信息,即这是一个关于毕业设计的项目,并且这个项目进行了重构,采用了Spring Boot框架进行重写。Spring Boot是Java领域广泛应用的...
毕业设计:本人精品课程毕业设计的重构,使用springboot框架重写
重构通常涉及重写代码,使之易于维护、理解,并且效率更高。重构包括很多细节的操作,例如重命名变量、分解长函数、移除重复的代码、提取类和接口等。《重构—改善既有代码的设计》(Refactoring: Improving the ...
然而,如果代码过于混乱或设计严重错误,可能需要考虑重写而非重构。同时,临近截止日期时,应避免仓促重构,以免影响项目进度。重构的工作量应纳入项目计划,作为单独的任务来处理。 在进行重构时,需要区分"重构...
重构的过程并不是简单的修改或重写代码,而是系统性地发现并解决代码中的设计问题,通过一系列小步骤来改进代码的结构,而不改变其外在行为。这些步骤包括提取函数、移动函数、提取类、引入参数对象等,都是书中详细...
在本项目中,"课设&大作业&毕设-本人精品课程毕业设计的重构,使用springboot框架重写.zip" 提供了一个基于Spring Boot框架的毕业设计重构案例。Spring Boot是一个流行的Java开发框架,它简化了创建独立的、生产级别...
- 如果代码过于混乱,可能需要考虑重写而不是重构,特别是当现有代码无法正常工作时。 ### 3. 代码的坏味道 **重复代码**:重复的代码意味着失去了代码复用的机会,应通过提炼函数或类来消除重复。 **过长的类/...