介绍

每个人都知道重构的含义； 敏捷编程的基础，以及不断提高代码质量的最佳途径。 但是重构并不总是相同的，可以定义两个不同的类别：

• 代码重构
• 架构重构

代码重构与体系结构重构

过去几年开始使用“ 体系结构重构 ”一词，使人们对其含义以及与代码重构的区别感到困惑。 有人可能会说没有区别，因为在重构体系结构时总是在代码级别进行重构。 因此，让我们尝试定义这两种类型并关注差异：

• 代码重构的目的是在不改变其行为的情况下修改代码，其主要目的是提高整体软件质量 。 一个重构通常是一个小任务 ，但是应用于代码的多个重构可以大大提高其质量。 已经写了几本关于代码气味和重构模式的书 。 最终，它存在能够检测代码气味 （FindBugs，PMD，CheckStyle）甚至进行自动重构 （NetBeans IDE）的自动工具。
• 架构重构旨在改变软件架构，将现有代码重组为新的逻辑层，其主要范围是提高整体软件质量并超越架构/基础架构限制 ，这些限制至关重要地挖掘系统质量，例如可伸缩性，可扩展性，可扩展性，可测试性和实际解决方案系统的稳定性 。 这种重构的主要挑战是试图重用尽可能多的现有代码，以避免编写新软件。 使用自动工具几乎没有帮助（也许只是检测循环依赖），在这里，大多数工作将来自您的大脑和经验。

那么区别是什么呢？ 重构代码时，我们会更改代码的编写方式，重构架构时，我们会更改代码在逻辑层和组件中的组织方式。

为了更好地描述差异，我将重点关注以下方面：

• 项目管理
• 发展管理
• 文献资料
• 实施环境

项目管理

从项目管理的角度来看，差异很大。 由于相关的风险较低且影响可以轻松控制和验证，因此代码重构通常在开发团队的范围内达成共识。

显然，对于架构重构而言，它是不一样的！ 必须与管理层达成协议才能启动任务，因为可以提高任务的相关风险和成本 。 跟您的经理交谈时该做什么和不该做什么的清单：

• 在进行任何讨论之前都要做一个高水平的计划，您必须对工作有个了解
• 列出针对实际限制的可实现的改进
• 尝试通过可量化的指标来确定投资回报率（取决于项目，但最常见的是金钱）
• 如果重构太大，请提出迁移计划
• 创建一个小团队，在重新访问体系结构时不容易让两个以上的人同时工作（至少在开始时）
• 永远不要说实际版本不好！

发展管理

代码重构是任何开发人员都可以完成的任务，因为存在许多辅助其执行的工具。 但是架构重构需要更多的专业知识，因为开发人员需要说一些软件架构才能理解更改，并且软件架构师需要成熟的经验，并且（在大多数情况下）需要很多勇气！

软件架构师有责任与参与重构的团队组织所有必要的会议，以与他们分享重构的理念和目标。 与代码重构不同，最好在开始工作之前对最终设计有一个完整的了解。

最后，确保保留实际的源代码，并且在操作环境中可以制定计划B，以准许工具的正常交付，以防重构任务会带来意想不到的困难，从而延误原计划。 计划B可以是例如与重构团队并行工作的小型开发团队，该团队将在实际系统中包括针对重构体系结构的最紧急的新要求。 这应该是管理层定义的迁移计划的一部分。

文献资料

代码重构不会像体系结构重构那样影响系统文档。 最重要的是，文档编写为：

• 迁移计划
• 重构的动机
• 影响和成本估算

现有文档列表将必须修改为：

• 系统设计文件
• 企业架构文档

实施环境

架构重构会对实施环境产生巨大影响; 例如，可能有必要更改使用的IDE或构建系统，持续集成服务器，测试自动化框架。 最好在开始重构之前分析这些影响，对任务的成本有一个现实的认识，因为实现环境中的意外更改可能会引起重大问题，而这些问题只有在最后阶段才能发现。

结论

以我的经验，我不得不面对几个大型的架构重构 。 考虑到所有上述4个方面，这帮助我成功完成了这些任务并获得了我的管理团队的信心。 最后，如果您是软件架构师，我想提到另一个方面，这是关于个人感觉的： 体系结构重构不是证明您的错误或错误决定的证据 ，只是在某个时刻它是必要的，并且这可能是最好的方法挑战并确认您的技能 ！

翻译自: https://www.javacodegeeks.com/2013/05/code-refactoring-vs-architecture-refactoring.html