2

我目前正在从事一个有一些（在我看来）架构问题的项目。

例如 - 每个对象都可以通过静态方法访问的公共框架 Bean 在需要时检索每个依赖项。这实际上只是一个将返回 Spring bean 的 spring 包装器。没有依赖注入。

实体引用 DAO 来检索关系数据 - 隐藏在实体 getter 中。

异常具有对解析和翻译错误消息的服务的引用。

每个服务或 DAO 都继承自一些通用的抽象框架 bean，这些 bean 有自己的依赖关系和配置要求。如果您尝试执行其他任何操作，您将收到“未初始化框架”错误。还应该提到的是，框架是一个没人敢碰的黑匣子。

每个测试实际上都是一个集成测试，因为它们都需要一个工作数据库连接到一个中央共享数据库。

我们有一个依赖图，基本上，一切都连接到一切。

并且没有测试。

想象一下在这种环境中设置单元测试是多么困难。事实上，每个测试都试图插入测试数据并自行清理——不使用任何类型的事务。

我只是在这里触及表面。

不用说，我有点担心代码质量。该项目（当然）时间和资源不足，并且截止日期即将到来。

那么 - 如果我们希望交付类似于功能软件的东西，如何用他们理解的语言说服管理层需要重构？

4

4 回答 4

1

在我看来，最好的方法是：

  1. Metrics：收集所有可能的关于使用当前架构引起的问题的数据。分析信息并将其划分为感兴趣的主题，例如：可靠性、效率、安全性和可维护性。（参见：软件质量）

  2. 视觉：使用分析的信息制作漂亮的条形图和饼图。

  3. 差异：将您的结果与标准或理想指标进行比较。

有了这个，您就可以向管理层展示您对项目的看法。

通常这项工作是项目经理、团队经理或团队负责人的职责。

祝你好运！

于 2013-02-05T19:41:24.617 回答
0

实际上，在许多情况下，重构可能对业务不利，因为收益小于成本。在其他情况下，收益可能大于成本，但成本太高，无法立即支付。尝试估计一些业务可以转换为$$$的单位的重构收益和成本，即开发人员、测试人员和支持团队的工时，系统不可用的小时数等，并让业务决定是否值得进行重构， 或不。这样的决策是业务比开发人员更强大的地方。

于 2013-02-05T18:42:45.857 回答
0

我正在开发一个依赖项相似的项目。单元测试并不理想。我在每个测试中都模拟了这么多类，因此在开发环境中简单地运行完整的应用程序是一个更好的解决方案。

我想这取决于您的应用程序。我的是一个服务 HTTP 请求的自定义 Web 应用程序。我打开它并发送各种请求以尝试遵循所有可能的路径。它更像是一个功能测试而不是单元测试，但我发现这个过程要快得多，而且我的日志语句提供的信息足以让我发现特定类或方法中的错误。

我写了我的代码，在开发中对其进行了功能测试。环境，然后找时间，慢慢的给类加了单元测试。

与他们讨论可能影响应用程序未来的预期变化、新功能、需求、技术等。如果项目永远不会发展，则可能不值得重构。

我并不是说功能测试是单元测试的替代品。

于 2013-02-05T21:10:23.007 回答
0

如果您认为需要说服“业务”了解重构的好处，那么您的想法并不是重构。重构是一种重新设计，但并非所有的重新设计都是重构。重构是一种小的、增量的设计改进。因为它很小，所以便宜又快。所以它不需要“业务”的批准：你可以去做。听起来您在这里真正拥有的是现有代码不适合目的。所以你应该试图说服他们，而不是试图说服他们需要做一些听起来像是不必要的“抛光”的事情。

于 2014-04-27T09:50:41.813 回答