重构遗留代码

时间:2012-01-02 15:09:41

标签: ruby-on-rails refactoring legacy

我正在开发一个非常大的传统Rails应用程序。大部分代码都是彻头彻尾的可怕,我正试图让它变得更好,因为我经历了它。

问题是,没有测试几乎所有内容都是错误的。到目前为止,我已经完成了代码并对需要重构的内容做了大量手写笔记,以便稍后在添加测试时可以这样做。

但有些事情只是如此简单,并且需要快速重构。例如:

def isValid(valid)
    name = Long::AndUglyModule::UglyClass.getvalid(valid)
    return name
end

整个班级看起来像这样,这让我想把它重写为

include Long::AndUglyModule

def is_valid(valid)
  UglyClass.getvalid(valid)
end
问题是,我害怕引入一些微妙的错误。另一方面,使用看起来像这样的代码会给我带来很多麻烦。

最好立即进行简单的重构,还是保留代码,直到我实际使用它或直接更改它?

1 个答案:

答案 0 :(得分:2)

我对巨大的遗留代码和整个重构有很多经验。

  • 允许混合新旧。
  • 明确区分两个代码库。
  • 记录例外情况。
  • 使旧代码更美观可能会浪费时间 10000%
  • 首先在有意义的地方重构:删除HTML框架集,声明性导航。用于繁琐构造的小功能。
  • 制作一个源处理应用,将代码中的反模式转换为更好的代码。还需要多源正则表达式查找和替换,\ 1用于识别重复。
  • 介绍旧代码太长的方法。
  • 缩小代码:复制&编辑了一个业务逻辑类,将所有内容保持在一起。
  • 明智的流程。

之前:从统计数据,KB,行数,已处理百分比,时间线开始。使用谷歌电子表格,可以传达进度,并计算结束日期。 遗留代码需要很长时间才被低估,所以请确保您拥有良好的文档。

还有更多要说的,但这与“小型重构”直接相关。

<强>结论:

一个人真的不能也不应该做任何事情来反对程序员重构小块的内在冲动,但重构应该是对多个源和事件的转换,或者在纠正或重新设计单个用例时。