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

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

我在这里反复遇到的越来越大的挫败感(我对整体工作非常满意,所以这不是一个“哦,不,我不喜欢我的工作”类型的帖子)是缺乏任何更大的设计或此 Web 应用程序的架构。该应用程序由几十个 JSP 页面组成,Servlet 或 Bean 或任何其他类型的框架中几乎不存在任何逻辑。很多JSP页面都是几千行代码,他们 jsp:include 在其他 JSP 页面中,业务逻辑与 HTML 混合在一起,频繁使用的代码片段(例如获取 Web 服务连接)被剪切和粘贴而不是重用,等等。换句话说,应用程序一团糟。

公司内部有一些传言,试图重新构建该网站,以使其更好地适合 MVC;我认为开发人员和高层开始意识到当前这种意大利面条式代码的模式是不可持续的,或者很容易扩展来为用户添加更多功能。高层和开发人员对完全重写这个东西持谨慎态度(有充分的理由,因为这意味着重写现有功能需要几周或几个月的时间),但我们已经对(缓慢地)重写进行了一些讨论。将网站的某些区域写入新框架。

使应用程序和代码库朝这个方向发展的最佳策略是什么?作为一名开发人员,我怎样才能真正快速地帮助推动这一进程,而又不会显得像一个刚入职的混蛋新人,告诉每个人他们写的东西都是垃圾?您在自己的工作经历中,遇到此类事情时,是否有使用过行之有效的策略或经验?

有帮助吗?

解决方案

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

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

其他提示

首先拿起迈克尔·费瑟的《工作》的副本 有效地处理遗留代码. 。然后确定如何最好地测试现有代码。最糟糕的情况是,您只能进行一些高级回归测试(或根本没有),如果幸运的话,将会有单元测试。然后,这是一个缓慢稳定的重构的情况,希望同时添加新的业务功能。

根据我的经验,应用程序的“优雅”通常更多地与数据库设计有关。如果你有一个 伟大的 数据库设计,包括定义良好的存储过程接口,无论您使用什么平台,良好的应用程序代码都会遵循。如果你有 贫穷的 数据库设计,无论您使用什么平台,您都将很难构建优雅的应用程序代码,因为您将不断地补偿数据库。

当然,中间还有很大的空间 伟大的贫穷的, ,但我的观点是,如果您想要良好的应用程序代码,首先要确保您的数据库符合标准。

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

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

我同意缓慢的重构方法;例如,将复制粘贴的代码提取到任何适当的 Java 范例中(也许是一个类?或者更好的是,使用现有的库?)。当你的代码确实干净简洁,但仍然缺乏整体架构策略时, 然后 您将能够更轻松地将事物融入到整体架构中。

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

您有一个用 1,000 多行长 JSP 编写的应用程序。它可能有一个可怕的领域模型(如果它真的有的话),并且不只是将演示与业务逻辑混合在一起,它还将其混合并坐在那里并持续搅拌几个小时。没有办法将蹩脚的代码移入 MVC 控制器类中,同时仍然做正确的事情,您最终只会得到一个具有贫乏域模型的 MVC 应用程序或具有数据库调用之类的内容的 MVC 应用程序在控制器代码中,你仍然失败。

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

迭代重构。还要寻找完全可以在新框架中完成的新功能,作为展示新框架价值的一种方式。

我的建议是找到不需要导入其他 JSP 或导入很少的罕见页面。将导入的每个 JSP 视为黑盒,并围绕它们重构这些页面(迭代地测试每个更改并确保其有效,然后再继续)。清理完这些内容后,您可以继续查找具有越来越多导入的页面,直到最终重构导入。

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

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

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

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top