189 8069 5689
目录
我经历过的一些重构
我理解的系统重构的关注点
过程中QA要做的事情
背景：使用了上古语言Delphi，共计300W行（包括底层3D引擎）代码，为了跟上新时代技术栈，需要整体切换到C++语言。集团内部提供了已验证的新版C++引擎，业务线需要将各自业务代码迁移至C++。
重构过程：
过程中的问题：1、任务估时逻辑不对，太过乐观。2、团队开发人员C++经验较少。3、按单个模块顺序重构，测试介入时间太晚，不可测性太高。4、历史功能逻辑梳理不够，开发中有很多漏需求的情况。
背景：一个极其庞大的单体PHP应用，由于业务数据量增长和性能需求，需要将其中核心业务拆解到JAVA微服务框架。
重构过程：
过程中的问题：1、对于微服务涉及的知识储备不够，开发中的技术调整的补全导致返工。2、产品需求list缺失，大多数历史逻辑是靠资深开发和测试确认和补回。3、虽然保障了web端的对外接口协议不变，可以通过自动化覆盖大部分改动，但是对于移动端api保障不足。4、中间遇到几次由于对java技术栈不熟导致的故障。
背景：网盘的PC端文件同步系统，由于历史遗留bug太多+逻辑庞杂，难以继续堆砌业务逻辑，决定重构。
重构过程：
过程中的问题：1、心态上负担大，历史名誉不好导致患得患失。2、前期重构规划不足，同时把从底层到前端全部重构，工作量大，新技术多。3、研发团队中缺少相关技术栈沉淀和人员储备4、开发质量太差，同一份用例每次执行都有很多bug（表现重复但底层原因各不相同）。5、缺少有效的测试手段，桌面客户端历史自动化沉淀太少，纯手工。6、产品只给了文件同步大原则逻辑，很多细节是边开发边确认的，导致有很多追加的工作量。
背景：公司有新旧两套媒资数据管理系统，基于统一研发应用+节省资源的需求，将业务系统中数据管理模块从旧应用迁移到新应用。
过程中的问题：1、本身改造复杂度大，需要兼容的点多。2、前后端都有变更，测试手段有限，历史积累自动化无法应用，绝大部分纯手工。3、历史产品逻辑细节较多，重构团队这方面缺少输入，经常出现漏处理的业务逻辑。4、缺少更细粒度的灰度发布手段（只能应用级别灰度）
我理解的系统重构的关注点1、重构狭义上看是技术层面的，业务逻辑无需改动，甚至上层应用都应该无感知。在重构规划时，应该尽可能往这个方向上靠拢，如果实在无法做到，那么风险极大。
2、重构另一个维度来看，也是业务的一个妥协，但也背着业务债。业务会有新的期待，新的要求，在技术规划时就要考虑到。
3、重构需要依赖功能清单（加粗）
重构前，已有能力清单应该明确并用来确认重构方案是否支持；
重构过程中，也可以根据这个清单评估工作量和进度；
测试时也要按照这个清单逐项验证。
这个清单应该足够细化，产品+测试+技术同学统一参与进来梳理。
4、可能会受影响的上下游应用都要评估到。关注他们的业务诉求和改造进度诉求。
5、引入新技术、新框架要提前做好知识储备+人员储备。边学边开发是一件要命的事情。
6、重构是一定一定需要测试介入的事情，从前期准备阶段就需要。可测试性需要从改造范围+技术方案+进度计划多个维度考虑。
7、重构期间尽可能专注，别受线上问题、业务压力影响，其他团队/职能帮忙分担些。
过程中QA要做的事情1、协助梳理历史需求和能力。
这个大多数情况旧系统都缺少文档沉淀、知识积累，甚至连当初设计的人员都不在了。测试大概率是最熟悉这个系统的角色，重构方案制定前，测试需要花较多时间来梳理、确认历史需求和能力，输出给研发，同时支撑自己的测试方案计划。
2、重构方案的可测试性评估和稳定性要求。
判断改造范围来确定可采用哪些测试手段，尽可能复用之前的自动化，也可以提测试需求（留后门接口、单测覆盖度要求）
尽早提出稳定性要求，比如灰度发布逻辑，可回滚逻辑，数据备份要求。
尽可能早的介入测试，可以提一些分阶段测试要求
3、提前准备好功能基线（功能清单）+非功能基线（性能表现），来评估重构后的质量表现。
4、如果发现上面有提到的可能导致质量风险的特征，要及时调整投入的测试资源，充分测试。
5、新技术的引入和使用。流量回放、灰度发布+监控、数据埋点
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧