如何表达为什么重构很重要

Question

我目前正在开展一个项目，其中包含一些（在我看来）建筑问题。

例如，当需要从每个对象都可以通过静态方法访问的公共Framework Bean中检索每个依赖项。这实际上只是一个包装弹簧的包装器，它将返回一个Spring bean。没有依赖注入。

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

异常引用了解析和转换错误消息的服务。

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

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

我们有一个依赖图，基本上所有东西都与所有东西相连。

没有测试。

想象一下在这种环境中设置单元测试有多难。实际上，每个测试都试图插入测试数据并在其自身之后进行清理 - 不使用任何类型的事务。

我只是在这里搔痒。

毋庸置疑，我对代码质量有点担忧。该项目（当然）运行时间和资源不足，截止日期即将来临。

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

Answer 1

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

1. 度量标准：收集有关使用当前体系结构导致的问题的所有可能数据。分析信息并将其分为感兴趣的主题，如：可靠性，效率，安全性和可维护性。 （见：Software quality）

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

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

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

通常，这项工作由项目经理，团队经理或团队负责人负责。

祝你好运！

Answer 2

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

Answer 3

我正在开发一个类似于依赖项的项目。单元测试并不理想。我在每个测试中都在嘲笑这么多类，只是在开发环境中运行完整的应用程序是一个更好的解决方案。

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

我编写了我的代码，在dev中对其进行了功能测试。环境，然后当我找到时间时，我慢慢地将单元测试添加到课程中。

与他们讨论可能影响应用程序未来，新功能，要求，技术等的预期更改。如果项目永远不会发展，则可能无法保证重构。

我并不是说功能测试可以替代单元测试。

Answer 4

如果您认为需要说服“业务”有关重构的好处，那么您的想法是不重构。重构是一种重新设计，但并非所有的重新设计都是重构。重构是一种小的，渐进式的设计改进。因为它很小，便宜又快捷。因此，它不需要“业务”的批准：您可以只是这样做。听起来你真正拥有的是现有代码不适合用途。所以你应该试着用它们来解决这些问题，而不是试图说服他们做一些听起来像是不必要的“抛光”的东西。