审计大型 java/j2ee Web 应用程序的最佳方法是什么

Question

我必须审核一个大型 Web Java/J2ee 应用程序，该应用程序已经发展了多个 年。它是由其他公司编写的，而不是我正在工作的公司。在 它的当前状态已经变得难以发展和维护，新的 功能很难添加，并且经常导致有时出现的错误 生产。似乎有一些复制/粘贴的代码导致代码重复。 当前的应用程序是某种在线购物，到处都有一些类似 cms 的内容。 在代码的较新部分中主要是 Struts 和一些 Spring，也许是一些 ejb 好措施。有一些可用的单元测试，但不是很多。 这些是我被告知的，我还没有看到实际的代码。

我的公司将提议重写此应用程序的部分内容，以减少 复杂性，提高质量和模块化，并使添加更容易 没有回归的新功能。 在做出任何承诺之前，他们希望得到某种赞赏 现有代码的质量，并评估其中有多少可以重用，以便 对必须做的事情有更多的猜测——完全重写或部分重写 重写。

问题是我必须在很短的时间内（几天）完成这项工作，所以我 试图为在这么短的时间内可以完成的事情制定一个计划。我的想法是：

• 查看“基本”内容 - 异常处理、日志记录
• 查看分层级别（视图、控制器、dao 层）
• 衡量单元测试的实际覆盖率
• 可能在项目上运行一些 Checkstyle、Findbugs 和 PMD
• ...

所以实际的问题是我应该考虑/检查/测量/等哪些其他事情？

我不确定我能从中得到什么样的数字，以及它是否真的意味着 某事，我觉得管理层的要求是错误的 方法，所以第二个问题是：有没有人有更好的主意？

我将不胜感激任何想法、建议和评论。

编辑：我将添加两个死代码检测器：UCD 和 DCD

Answer 1

我有两个与您设置相似的 Web 应用程序。我停止使用 FindBugs 和 Checkstyle，因为它们显示了超过 10.000 个问题点。应用程序使用 JDBC 级别的数据访问、用于表示的 JSP 和用于请求分派的自定义框架。对我来说幸运的是，这些低级设置使我能够在中等难度下进行扩展和修复。在 3 年的项目中，只有大约 20% 的原始代码保持原样。迟早，其他一切都需要更改、替换或删除（最后我能够使用 FindBugs 和 Checkstyle）。

我们也面临着完全重写的困境。但是，有几个因素不利于它：

• 不确定客户是否会为完全重写付费。
• 功能和技术文档的缺乏使得完全重写存在风险。
• 完全了解完整应用程序的工时太高。客户希望尽快进行请求的更改。
• 习惯于演示和页面行为的用户。似乎很难说服用户为旧功能使用新界面。
• 如果我们进行完全重写，我们需要提供完整的文档。为了更新，我们只需要记录我们的部分。
• 如果程序正常工作（或多或少），很难说服管理层（自己和客户的）重写
• 公司有自己的PMD规则，代码没有通过。更简单的说法是，新部件通过测试就足够了。

它归结为你想要做的事情。

尽管很复杂，你想重写吗？

• 强调代码错误。带有大量红色的大饼图令人信服。
• 解释计划属性以及它们如何不符合公司愿景。
• 显示超出当前要求的增强选项，并说明当前版本无法应对挑战。
• 采访真实用户。他们可能会指出当前版本的重要问题。
• 价格便宜，但估价高。您可能会将一些费用推迟到维护阶段。

你不想重写？

• 强调成本，尤其是客户重新测试一切所需的工时。
• 指出破坏功能的潜在问题。
• 要求全职文档编写者。

如果您想品尝代码，请尝试添加 Hello World！应用程序的功能/屏幕。这说明了您实施新事物的难度和速度。

Answer 2

事实上，他们不会为完全重写付费，因为：

• 经济不景气，从头重写的成本会很高

• 他们可能试图尽快出售公司

• 管理层对软件开发一无所知

我会先讲一些简单的事实：

• 使用工具显示项目的SLOC
• 按照您的计划运行 FindBugs 并最终运行 PMD，只是为了估计缺陷
• 进行快速分析会话
• 检查不同的层
• 查看资源是否普遍关闭（流、Hibernate 或 JDBC 连接等）
• 查看技术是否用于不适用的地方（EJB、Web 服务等）
• 了解它们如何处理异常和日志记录
• 查看抽象是否过多或不足
• 看看是否可以添加一些基类来减少代码重复

如果他们没有提供相关文档，请尝试快速绘制应用程序架构图。

收集一些统计数据和一些事实，写一份报告并发送给公司。他们会希望将成本降到最低，并且会要求您避免修复未损坏的代码。您从统计数据开始，然后是事实和提议，包括时间/受影响的代码的大致百分比/定价。

通常遗留的 Struts 应用程序是一个需要维护的皮塔，一直在那里。如果这不是你工作的一部分，我会说放手。如果您遇到“独立”页面，这些页面不涉及很多模板并且会进行很多更改，建议您使用其他技术重写它们。

Answer 3

您关注的是可维护性和可扩展性。

我会添加查看重新启动项目需要多长时间。他们使用源代码控制吗？他们是否有用于集成和用户验收测试的单独环境？有构建服务器吗？

当您必须在第一个改进出现之前花费两个月的时间时，有人需要预先管理客户的期望。

Answer 4

我非常喜欢你的清单。我认为你有一个很好的进攻计划。

我会着眼于在 Spring 或 EJB 3.0 上实现标准化，但不会同时在两者上实现标准化。

我自己没看过，不知道Michael Feathers的书"Working Effectively With Legacy Code"有什么好主意吗？

更新：

也许您可以通过将它们置于自动构建和持续集成中来提供帮助 - Cruise Control、Hudson 或 Team City。如果您必须进行任何重构，它会有所帮助。