当前位置：首页 > article >正文

系统分析与重构指南：现代软件工程的质量提升策略

article 2024/11/25 16:47:36

系统分析与重构指南：现代软件工程的质量提升策略

引言

在快速变化的软件开发领域，系统分析与重构已成为保持技术架构健康和竞争力的关键手段。本文将深入探讨系统分析与重构的核心原则、方法论和最佳实践，帮助开发团队系统提升软件系统的质量和可维护性。

为什么重构

创造更多的价值
改善既有代码的设计。副标题是最好的说明。
帮助找到软件中的 bug。review 旧有代码的过程中，会发现一些不符合业务的代码。
提升开发效率。让代码易于扩展

系统分析的关键步骤

全面系统诊断，技术债务评估：识别需要重构的地方
重构策略与实施：制定重构计划，执行计划的重构任务
实施保障措施：使用测试对重构是否影响业务功能进行检察
调整下一次重构策略

全面系统诊断

系统分析的首要任务是进行全面而深入的系统诊断，我们需要知道整个过程的工作原理。。这一阶段需要:

通过性能监控工具收集系统运行时数据。
分析系统架构的关键指标，包括响应时间、资源利用率和错误率，分析出性能瓶颈在哪里。
识别系统的性能瓶颈和架构组成
也需要了解以前的系统是如何工作的。从编译、测试和部署开始，直到收到用户请求。

技术债务评估

技术债对于软件的影响：可维护性（Maintainability）、可演进性（Evolvability），而这些技术债对于非技术人员来说都是不可见的。它们源于生活，藏于黑暗中。技术债务评估是系统分析的核心环节。开发团队需要:

使用静态代码分析工具扫描代码质量
评估代码复杂度和圈复杂度
识别重复代码、过时依赖和不规范的编码模式

重构策略与实施

开始重构之前

拉通，对齐目标：会遇到不一样的需求，有的是明确的重构需求，有的则是隐藏在需求之后，有的则是看上去没有而已。
明确潜在风险
人评估：并非所有的人都具备足够的能力参与到重构的过程中。所以，在我们进入重构之前，需要：
- 确保对方有足够的能力
- 确保和对方对于重构有共同的看法
- 确保对方能配合你工作

重构方法论

采用渐进式重构方法，确保系统稳定性：
增量重构：将大规模重构拆分为可管理的小型迭代

保持向后兼容性

在重构后的服务中，我们可能会对已有的数据库、交互接口、中间件等进行变更。
为了保证后续新老服务的平滑升级，在确认新服务的模型后，还需要对旧服务进行开发，让其兼容新服务的模型，可能包括但不限于数据库迁移、中间件升级新增、接口变化等等。经过测试后，发布线网环境。

先重构，后优化

优化的第一条规则——不要优化
优化的第二条规则——还不到优化的时候
优化前先性能指标分析，分析出性能瓶颈

建立全面的自动化测试体系

在测试环境里，对所有测试用例进行测试，完成所有基本功能和压力测试。这里需要同时对新老服务进行单元测试，保证相同的功能接口的输出一致。
在线网独立部署测试环境，测试使用的数据必须是从真实环境复制下来，部署独立的数据库，缓存等服务，避免影响生产环境。
再做一次对所有测试用例进行测试，完成所有基本功能和压力测试
这里开始做集成测试，完全模拟用户的操作行为，对服务进行测试。此时测试人员主要是内部人员

重构技术

关键重构技术包括：

提取方法：将复杂函数拆分为更小、更focused的函数
对象组合：优化类之间的依赖关系
抽象层重构：简化复杂的继承结构
调用关系
- 尽量避免两个服务相互调用，在相互调用时，需要确认是否会产生循环调用
- 同步调用应该避免循环依赖，可以异步调用的请求考虑使用MQ解耦合

架构演进原则

微服务解耦
模块化设计

实施保障措施

测试驱动重构：单元测试覆盖、集成测试策略、端到端测试场景设计
持续集成与监控：自动化构建流程、性能指标实时监控、异常报警机制

重构风险管理

风险评估

新老系统功能的兼容
- 主要在于老数据，在新系统功能中可用、展现完整，并且可以按新功能继续向下走。
- 对于旧系统识别到的一些坑，尽量避开就是。
- 后期做测试，要更多的关注旧数据在新系统中的表现。
老数据迁移新系统后的数据完整性，兼容性，异常数据的处理问题
- 若不完整，需要补充，否则新功能在展现旧数据时，会出现不可用的情况。
- 比如由于表结构不一致，表字段不统一，新增的扩展数据等等。
老系统的接口在新系统中是否保持统一，否则要重新对外变更接口，比如端口、方法名、参数、返回字段等等，尽量保持接口定义不变，造成不必要的麻烦。重构涉及到的接口无论是否有变更都有和前端做对接
确保新系统与外部系统的交互是否完整，新系统接替旧系统，与外部系统的交互同样要保留，不能新系统一上线，其他的系统服务涉及到旧系统的地方不可用。
业务逻辑时间较久，无人清楚
- 针对一些特别老旧的系统，且在文档缺失严重的情况下，必须深入旧系统的使用、全面了解旧系统的业务功能，以便能在新系统中完整的保持功能。
- 产品研发一起梳理业务逻辑
- 模块迁移的技术文档需要增加数据表结构的对比，并且周知数据/产品/QA/上下游服务
迁移系统分主次，尽量避免统一迁移，而是逐步迁移
- 建议采用“迭代式”重构。考虑将一次重构拆分为多次“迭代”行为
- 每一个重构步骤能快速部署上线并得到反馈，以便评估重构的效果，及时作出调整
- 从项目风险的角度来说，通过将重构分成多个迭代，能有效的控制迭代的风险
- 每一个步骤，重构团队（开发和测试）都能集中一点吃透，并进行充分的测试
- 每次重构/新系统上线的工作量，不应该超过1个正常的迭代（2周时间）
数据合规：在迁移数据的时候，需要跟产品经理、法务相关确认这个数据是否会涉及到数据合规问题
数据兼容：一般情况下，业务逻辑无任何变更，新旧系统数据都可以兼容，如果在迁移服务发现数据无法兼容时，需要研发和产品一起讨论解决方案
服务依赖：在迁移过程中，不可避免可能会出现服务依赖，服务评估出服务间的依赖顺序，参考依赖顺序迁移服务

新老系统迁移方案

系统迁移的主要任务包括：前期调研、数据整合、数据迁移、接口灰度、系统监控、业务回滚、应急预案
- 前期调研：对原系统做一次彻底的全面了解，主要需要的考虑的有下面一些情况
- 原系统网络结构、业务范围、业务流程、数据流程、数据结构、存在几套业务系统以及他们之间的依赖关系；
- 原系统的数据分布状况：包括数据范围、数据量大小、与第三方系统交互等；
- 配合前端梳理出现行接口，并统一接入网关
- 数据整合包含两个步骤：数据整理与数据转换
  - 数据整理就是将原系统数据整理为系统转换程序能够识别的数据；
  - 数据转换就是将整理完成后的数据按照一定的转换规则转换成新系统要求的数据格式
- 数据的整合是新旧系统切换的关键；
- 数据迁移：数据整合完成之后，就会设计到数据迁移，将旧系统中的数据通过在数据整合阶段整理出来的转换规则在数据迁移阶段，将数据迁移到新系统数据库
- 接口灰度：在数据迁移完成之后，接口需要进行灰度放量，以便于进行业务运行情况观察
- 系统监控：在新系统上线后，验证对新系统运行的有效性和正确性，发现问题时，可以及时对数据转换过程中出现的问题进行纠正。
- 业务回滚：在接口灰度发现业务出现问题时，应该马上停止灰度，流量切换到旧系统，研发团队进行问题排查，代码修改，重新上线继续进行灰度
- 应急预案：在特殊情况下，由于某种原因导致系统没有能够正常切换或者切换以后系统运行不稳定，在这种情况下，必须启动应急预案来解决。

为最大化地减少服务重构对业务的影响，可以参照本文的流程执行业务切换并建立回滚方案。