|
03 执行过程中有哪些可分享的经验？ 这次重构能够实施得如此顺利，有 4 点我认为很有价值的经验跟大家分享下。1. 高质量的技术设计方案 这一点得益于日常的要求，针对开发周期超过3天的项目我们都会进行技术方案设计，本次重构当然也不例外。
框架部分的整体架构、模块之间的协议设计、以及策略的可扩展性设计是本次技术方案的重点，团队前后讨论了不下3次。 在大方案定稿后，团队进一步对数据库、接口字段、缓存结构、日志埋点等公共部分进行了细化，因为涉及到多人协作开发，团队约定以文档作为沟通界面，文档始终保持和代码同步。
在这样的高要求下，团队产出了 5000 多字的技术方案文档，合计 36 页，这些为整体质量的保障打下了很好的基础。2. 预重构出框架性代码 这一个 PR 非常关键，是我们从技术方案落地到代码最重要的一步。我们把重构后的包结构、模块划分、各层之间的API定义、不同广告策略的抽象进行了梳理，先忽略实现的细节。
这样主体代码基本成型，能很清楚地描绘出我们理想中的框架。然后，我们组织了多次集中代码审查，最终形成了统一意见。 这一步能很好地避免过早陷入实现细节，导致主体框架关注不够、代码不稳固，后期再返工反而会拖累效率。 3. 频繁沟通和成对代码 Review 机制 进入到细节实现阶段后，很重要的一点是：对现有逻辑的理解。引擎代码经过一年半的迭代，历史上被很多人开发过，但是本次只有 3 个同学参与重构。
整个过程中，我们遇到任何代码逻辑不明确的地方，都是反复沟通和求证，不主观猜想，这一份谨慎其实很关键。 另外在代码审查上，我们按模块分配了对这块业务比较熟悉的同学来负责，成对搭配，机制灵活。 4. 有效的测试方案 重构未动，测试先行。这个原则是《重构》一书中重点强调的，也是我们本次技术方案讨论的重点，我这里单独拎出来详细展开下。 首先，我们前期便约定好：不动任何老代码，完全建新的 package 进行重构。这样方便比对重构前后的结果，同时进行线上灰度实验。 测试方案上，以下 4 点值得借鉴： 1、端到端测试：本次重构不涉及功能性的调整，因此外层API的行为是不会有任何变化的，这样端到端的测试方法最为有效，这个是研发和QA测试最主要的手段。 2、冒烟测试：QA同学提供冒烟 Case，由研发同学进行冒烟，研发提测前必须保证所有冒烟 Case 执行通过。这一点在大部分互联网公司都不常见，但是对于大型项目绝对有效。 3、沙箱环境双流程验证：前面提到我们重构前后的代码都保留了，因此可以通过脚本抓取线上环境的入参作为case，然后用自动化的方式对 API 的返回字段进行逐一比对。
4、线上环境灰度实验：灰度对于重构非常重要，我们利用已有的ABTest平台，逐步放开灰度流量，从5%、到10%、到30%、最后到100%，制定了很谨慎的放量节奏，然后通过日志以及业务指标监控进行验证。
| 
楼主
标题置顶
标题高亮
