0

我们是一个致力于 Rails 2.3 项目的小团队。简短说明：该项目目前已

  • 460 000 行 Ruby、CSS、JS 和 YML（包括一些插件和库）
  • 350 个 ActiveRecord 类（仅项目的类）
  • 最近的类和控制器中的一些 Rspec 测试（还不够）
  • 需要 45 颗宝石
  • 包含 2 个 Go 数据的数据库。

该项目分为大约 15 个“模块”（不是 Rails 模块），每个模块都与其他模块通信。这个项目存在好几年了，并且已经由几个人改进和维护，而不是必要的 Rails 专家。

当前的主要问题是代码的几个部分难以维护，未优化且不够“周到”（到处都有破解）。CSS 文件几乎不可读。

我们的团队正在考虑重构这个项目。我们有几个解决方案：

  • 从头开始创建一个新项目，并一一包含功能。这个解决方案的优点是我们拥有项目的所有方面，并且我们可以对代码设计做出更漂亮的决定。另一个优点是我们可以更新到 Rails 3。缺少这种方法是当我们必须包含新功能时，我们必须并行维护 2 个项目。

  • 逐个模块更新现有代码。这种解决方案的优点是我们只保留一个项目来维护。但是有几个不足......如何从旧模块转到新模块？如何在新旧类名之间进行？如何知道旧代码在哪里被使用并且必须被删除？......甚至更多。

有没有人已经进行过这样的大重构？

有没有人对此有经验反馈？

有没有人有其他解决方案？

谢谢阅读 ！

4

2 回答 2

3

这里的答案实际上取决于您拥有多少自主权以及您可以投入多少时间进行重构。对于这种规模的项目，几乎可以肯定的是，您不能只是停止所有工作并将 100% 的时间投入到清理ROR 3 迁移（咳咳，迁移！）。

如果我的假设是正确的，那么我的建议是使用第二种方法（例如更新现有代码）以小块方式解决这个问题。除了您概述的内容之外，我还会鼓励其他一些事情：

  • 在重构一段代码之前编写测试。这将帮助您确信您没有引入问题（强调帮助......当然可能会出现一些破损）。
  • 在可能的情况下，考虑将模块分解为单独的、独立的 gem。这将帮助您跟踪外部依赖项并找出所有 45 个外部 gem 的使用位置。它还有助于限制测试的范围。

坦率地说，第二种方法对您作为开发人员的工作来说更安全，因为它允许您改进代码库，同时响应其他业务需求。如果重构的一部分进行得太慢，您也可以停下来在其他地方重新开始，因为代码库的其余部分仍然完好无损。

于 2013-03-20T14:54:45.220 回答
2

重构是一项繁重的工作，需要很长时间和很多思考。

与一个全新的项目相比，问题在于您必须维护一个工作项目，并且可能必须随时支持一些错误修复和功能请求。

另一方面，您对正在解决的问题有更好的理解，并且可以将现有软件用作您事实上的“功能规范”

  1. 通过列出每个相互依赖关系来识别“模块”之间的接口。
  2. 如有必要，清理这些“接口”
  3. 通过编写单元测试来形式化接口以测试每个模块的输入和输出
  4. 创建全新的模块作为替代品。从头开始架构师，并在此处进行 ruby​​ 升级。确保您的新模块通过与旧模块相同的测试。
  5. 如有必要（作为临时解决方案）包装各种不兼容的部分以使它们一起工作。这可能很慢，但这是一个权宜之计。

祝你好运。

于 2013-03-20T14:55:05.120 回答