0

征求有关升级（或重写？）旧版应用程序的建议。它是一个单页 web 应用程序，具有许多动态生成的窗口和表单，大致由

  • .rb 文件中有 13,000 行
  • .erb 文件中的 11,000 行
  • 25,000 行 javascript（不包括将其带到接近 60000 行的大型 3rd 方库）

这充当了我们系统最终用户的 UI，该系统还具有许多核心业务服务（主要用 Java 编写，带有少量 Node.js）和相当大的 MySQL 数据库（>200GB）。其中一些服务将 AJAX 推送到客户端浏览器以进行实时更新。

升级原因

  • 它是 ruby​​ 1.8.7，rails 2.3.15。大多数核心代码都可以追溯到 2009 年。这使得它既不安全又难以维护（认为“早于 gemfile 的存在”。）
  • 该应用程序大部分时间都由 Java 开发人员维护，因为该公司的大多数开发人员都被聘为 Java 开发人员来处理执行业务逻辑的所有其他服务。可以安全地假设这导致了许多不想破坏任何东西的人的黑客攻击，当然很多不会以“rails 方式”完成。
  • javascript也有点乱。它有一堆框架（最初的 Angular 被零星使用；jquery 和原型都在不同的地方争夺 $ 符号。）有 7000 行长的文件。
  • 自 2009 年以来，CSS 样式已经升级（！），但开始看起来有点累了。我们希望实现一个无需太多前端技能就可以看起来很清晰的引导程序主题，但是现在如果我们尝试添加引导程序，渲染我们所有的弹出窗口、侧边栏等的代码会严重损坏。
  • 对我们的推送服务器进行现代化改造，用 websocket 代替它们会很好。

语境

开发团队中有 3 个人——这是我的第一份工作，我从一月份才来这里。在另外两个中，一个只比我长了大约 4 个月，这也是他的第一份开发工作。另一个人是唯一一个曾经和原团队的人交谈过的人。

哦，当然，我们几乎没有或没有测试覆盖率。

选项

当我被聘用（作为一名 Java 开发人员）时，我被告知我们正在寻找一个基于 Spring MVC 的网站来替换该网站。这项工作正在部分进行，几年来一直受到点滴和单调的攻击。因为素未谋面的不同开发者对它进行了攻击，就好像这是他们自己的全新项目一样，相同的问题在不同的地方以不同的方式解决。他们尝试了一些华丽的技术，例如我发现很难遵循的自定义注释，但据我所知并不能完全奏效。我们中最资深的人估计我们的团队需要一年的专职全职工作才能完成它（这不是一个现实的商业提议，基于我们从客户那里获得的对新功能的请求数量）。

我倾向于升级网站而不是推出一个新网站。这部分是因为我可以看到那个 帖子的意义。另一个原因是我们都被聘为全栈开发人员（兼任 DBA、系统管理员等）。我们在 UI 设计方面没有什么特别的专业知识，而我们当前界面的 UI 虽然已经过时，但非常人性化；感觉就像一张空白的画布会把那个结构扔掉，并发挥我们的弱点。升级 ruby​​/rails 也会使我们在升级期间添加的任何功能更容易添加到新站点。

显然，一些经验丰富的 ruby​​ 开发人员是我老板的朋友，他们非正式地建议他，让网站保持最新状态需要做很多工作，这相当于完​​全重写，这就是 spring 项目的动机。这样做的好处是只需要考虑 Java + javascript，而不是试图雇佣既了解 Java 又了解 ruby​​ 的人。

传统智慧似乎是分阶段升级轨道。我不确定这对我们有多好，原因有两个。一方面，有 3 个主要版本供我们升级，它们之间可能会有重大变化。更重要的是，代码无论如何都需要一些 TLC 来重构和创建测试套件。

我倾向于遵循以下策略：

  1. 将一些开发人员时间投入到培训中，以了解相关的最佳实践和做事的“rails 方式”，而不是我们大多数人现在拥有的“足以破解”的知识。
  2. 在 ruby​​ 2.4.0 上启动一个新的 rails 5.1 项目
  3. 配置活动记录以使用我们的旧数据库
  4. 将现有项目的公共文件夹中的 javascript 复制到资产管道的相关部分，并为“第 2 阶段”保存这个令人头疼的问题。
  5. 用我们的依赖项的更新版本整理一个 gemfile（例如，mysql gem 已被 mysql2 gem 替换。）此时安装rubocop似乎是个好主意。
  6. 一次将文件从旧项目复制到新项目。阅读代码，弄清楚它在做什么，编写相关的测试，修复它们中断的地方。使用 ruby​​ API 和 rails 升级指南来更新语法。重构直到 rubocop 被安抚。
  7. 一旦我们复制了现有网站的功能，就写一篇关于如何整理 javascript 的新 stackoverflow 帖子；）

这听起来确实需要做很多工作，但与尝试用不同的语言从头开始重现我们现有的功能相比，这似乎不太可能产生错误的混乱。所以...

问题

  1. 这个策略看起来合理吗？在这种情况下，重写真的是更好的选择吗？单独处理 JS 是最好的调用，还是在我们从视图中检查对它的调用时重组它更好？或者我们真的应该升级 -> 3.0, 3.1, ... 5.0, 5.1？
  2. 我们手动更改了数据库，直接添加新表、新字段等，而不是使用 . rails generate. 'Rails magic' 似乎目前可以使这项工作发挥作用，但我们是否应该预料到第 3 步中的问题？
  3. 是否有任何逻辑顺序来处理红宝石的迁移？由于作为应用程序的中心入口点的路由发生了重大变化，从那里开始，然后是身份验证，然后是主页，然后一次添加一个功能似乎是明智的。
  4. 部分问题是“不知道我们不知道什么”关于 Rails 的做事方式。除了规范的 Ruby/Rails 教程（Hartl、Ruby Monk、Ruby Koans、Kehoe 的 rails book）之外，在尝试承担如此庞大的工作之前，我们还应该注意哪些必要的阅读内容？我特别在想一些可能不是很明显的事情，比如正确使用辅助函数、模块结构等。
  5. 任何其他建议，评论，祈祷，......欢迎！
4

0 回答 0