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

时间:2013-02-05 18:31:34

标签: java spring architecture exception-handling entities

我目前正在开展一个项目,其中包含一些(在我看来)建筑问题。

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

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

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

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

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

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

没有测试。

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

我只是在这里搔痒。

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

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

4 个答案:

答案 0 :(得分:1)

在我看来,最好的方法是:

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

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

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

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

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

    祝你好运!

答案 1 :(得分:0)

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

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

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

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

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

答案 2 :(得分:0)

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

答案 3 :(得分:0)

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