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

Question

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

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

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

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

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

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

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

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

Answer 1

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

我会着眼于 Spring 或 EJB 3.0 的标准化，但不会同时关注两者。

我自己还没读过，但我想知道 Michael Feathers 的书 “有效地与遗留代码》有什么好的想法吗？

更新：

也许您可以通过自动化构建和持续集成来帮助解决问题 - Cruise Control、Hudson 或 Team City。 如果您必须进行任何重构，它会有所帮助。

Answer 2

您非常关注可维护性和可扩展性。

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

当您必须花费两个月的时间才能出现第一次改进时，就需要有人提前管理客户的期望。

Answer 3

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

• 现在是经济衰退，你从头开始重写的成本会很高

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

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

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

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

尝试绘制架构的快速图表如果他们没有给您有关申请的文件。

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

通常，遗留的 Struts 应用程序维护起来很麻烦，已经做过了。 如果这不是你工作的一部分，我会说放弃它。 如果您遇到不涉及很多模板并且会进行很多更改的“独立”页面，建议使用其他技术重写它们。

Answer 4

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

我们也面临着完全重写的困境。 然而，有几个因素反对它：

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

它归结为你实际上想做的事情。

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

• 重点关注代码错误。 带有大量红色的大饼图很有说服力。
• 解释该计划的属性以及它们如何不符合公司愿景。
• 显示超出当前要求的增强选项，并描述当前版本无法应对挑战的原因。
• 与真实用户进行访谈。 他们可能会指出当前版本的重要问题。
• 便宜但善于估算。 您可能会将一些费用推迟到维护阶段。

你不想重写吗？

• 重点关注成本，尤其是客户重新测试所有内容所需的工时。
• 指出破坏功能的潜在问题。
• 要求一名全职文档撰写者。

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