将现有凌乱的 web 应用程序迁移到优雅的 MVC 的最佳方法是什么？ [关闭]答案

【问题标题】：What is the best way to migrate an existing messy webapp to elegant MVC? [closed]将现有凌乱的 web 应用程序迁移到优雅的 MVC 的最佳方法是什么？ [关闭]
【发布时间】：2010-09-07 14:27:22
【问题描述】：

大约一个月前，我加入了一家新公司。该公司规模较小，具有很强的“初创”感。我在一个由 3 人组成的团队中担任 Java 开发人员。该公司主要向企业/业务类型的人销售一种服务，用于相互交流。

我过去和将来的主要工作之一是公司的主要网站 - 从中出售服务，现有用户登录以检查他们的服务并支付账单，新用户可以注册用于试用等。目前这是一个部署在 Tomcat 上的 JSP 应用程序，可以通过公司自己编写的持久层访问数据库。

我在这里遇到的反复和日益增长的挫败感（我对这份工作总体上很满意，所以这不是“哦，不，我不喜欢我的工作”之类的帖子）是缺乏任何此 Web 应用程序的更大设计或架构。该应用程序由几十个 JSP 页面组成，在 Servlet 或 Beans 或任何其他类型的框架中几乎不存在任何逻辑。很多JSP页面都是几千行代码，他们jsp:include其他JSP页面，业务逻辑混在HTML里，经常用到的sn-ps的代码（比如获取web服务连接）都是剪切粘贴的比重用等。换句话说，应用程序是一团糟。

公司内部曾传出一些谣言，试图重新设计这个网站，使其更适合 MVC；我认为开发人员和高层开始意识到这种当前的意大利面条式代码模式是不可持续的，或者很容易扩展为用户添加更多功能。高层和开发人员对完全重写事物持谨慎态度（有充分的理由，因为这意味着重写现有功能需要数周或数月的工作），但我们已经讨论过（缓慢地）重新编写将网站的某些区域写入新框架。

有哪些最佳策略可以让应用程序和代码库朝着这个方向发展？作为一名开发人员，我如何才能真正帮助快速推进这项工作，而不是看起来像一个刚入职并告诉每个人他们写的东西都是垃圾的混蛋？当您遇到此类事情时，您在自己的工作经历中是否使用过任何行之有效的策略或经验？

【问题讨论】：

标签： java model-view-controller jsp architecture

【解决方案1】：

您最好的选择可能是在进行过程中慢慢重构它。很少有人拥有从头开始完全从头开始的资源，其中隐藏着如此多的业务规则。当您花费数月时间开发一款错误比您替换的应用程序更多的应用程序时，管理层真的很讨厌它。

如果您有机会从头开始构建任何单独的应用程序，请使用那里的所有最佳做法并用它来展示它们的有效性。尽可能将这些想法逐渐融入旧应用程序中。

【讨论】：

【解决方案2】：

我的建议是找到不需要导入其他 JSP 或很少导入的稀有页面。将每个导入的 JSP 视为一个黑盒，并围绕它们重构这些页面（迭代地测试每个更改并确保它在继续之前有效）。清理完这些后，您可以继续查找具有越来越多导入的页面，直到最终重构了导入。

重构时，请注意尝试访问未提供给页面的资源的部分，并尝试将其取出到控制器。例如，任何访问数据库的东西都应该在控制器内部，让 JSP 处理控制器通过转发提供给它的信息的显示。这样，您将为每个页面开发多个 servlet，或类似 servlet 的东西。我建议使用基于前端控制器的框架进行这种重构（根据个人经验，我推荐 Spring 及其 Controller 接口），这样每个控制器都不是单独的 Servlet，而是委托给一个适当映射的 Servlet。

对于控制器，最好一次完成所有数据库命中，而不是零碎尝试。用户可以并且通常确实可以容忍页面加载，但是如果将所有数据库数据都提供给渲染代码而不是渲染代码挂起并且在客户端尝试读取另一个数据时不向客户端提供数据，则页面输出会快得多数据库中的一条数据。

我能感受到你的痛苦，并祝你在这项工作中好运。现在，当您必须维护一个滥用 Spring Webflow 的应用程序时，那就是另一回事了 :)

【讨论】：

【解决方案3】：

迭代重构。还要寻找可以完全在新框架中完成的新功能，以此来展示新框架的价值。

【讨论】：

【解决方案4】：

首先拿起一份 Michael Feather 的工作 Effectively with Legacy Code。然后确定如何最好地测试现有代码。最坏的情况是你只被一些高级回归测试（或根本没有）困住，如果你幸运的话，会有单元测试。然后是一个缓慢稳定重构的案例，希望同时添加新的业务功能。

【讨论】：

【解决方案5】：

最好的方法是将代码打印出来，揉成一团，然后扔掉。甚至不要回收纸张。

您有一个用 1,000 多行 JSP 编写的应用程序。它可能有一个糟糕透顶的领域模型（如果它甚至有一个），它不只是将表示与业务逻辑混合在一起，它混合了它并坐在那里并持续搅拌几个小时。没有办法取出蹩脚的代码并移入 MVC 控制器类并且仍然做正确的事情，你最终会得到一个具有贫血域模型或具有诸如数据库调用之类的东西的 MVC 应用程序在控制器代码中，您仍然失败。

您可以尝试一个做正确事情的新应用，然后让这两个应用相互通信，但这本身就是新的复杂性。此外，如果您从头开始，您可能会做同样多的工作，但您可能更容易说服您的老板这是一个更好的方法。

【讨论】：

【解决方案6】：

我同意缓慢的重构方法；例如，将复制粘贴的代码提取到适当的 Java 范式中（也许是一个类？或者更好的是，使用现有的库？）。当您的代码非常干净简洁，但仍缺乏整体架构策略时，那么您将能够更轻松地将事物融入整体架构。

【讨论】：

【解决方案7】：

这在仅处于维护模式的应用程序中更难做到，因为很难让管理层相信重写已经“工作”的东西是值得的。我将首先将 MVC 的原则应用于您能够处理的任何新代码（即将业务逻辑移动到类似于模型的东西，将所有布局/视图代码放在一个地方）

随着您在 MVC 中获得使用新代码的经验，您可以开始看到巧妙地更改现有代码以使其符合要求的机会。这可能是一个非常缓慢的过程，但如果您能够展示这种方式的好处，那么您将能够说服其他人并让整个团队参与进来。

【讨论】：

【解决方案8】：

根据我的经验，应用程序的“优雅”通常更多地与数据库设计有关。如果您有一个出色的数据库设计，包括定义良好的存储过程接口，那么无论您使用什么平台，都倾向于遵循良好的应用程序代码。如果您的数据库设计糟糕，那么无论您使用什么平台，都将很难构建优雅的应用程序代码，因为您将不断地对数据库进行补偿。

当然，great 和 poor 之间有很大的空间，但我的观点是，如果你想要好的应用程序代码，首先要确保你的数据库符合鼻烟。

【讨论】：