导读：在产品运行过程中 ， 因为一些业务或者技术上的问题需要通过代码重构来改善产品的性能 ， 这就是技术重构 。 那么在这个过程中 ， 产品需要做些什么呢？文章结合案例从3个方面展开了说明 ， 与大家 。

文章图片

Q2参与了公司一款细分场景下数据产品的技术重构 ， 经历3个月左右的时间 ， 在团队同学的齐心协力下比较顺利的完成了目标 。 想通过文章复盘在技术团队驱动的重构项目中 ， 作为产品经理 ， 应该为团队做的事 。
01 什么是技术重构？
先补充一下本次重构的背景：
该产品在细分赛道内拥有较大的用户规模 ， 上线后已经稳定运行多年 ， 面对不断增长的用户数量 ， 原有的技术方案出现了不足 ， 基于这样的背景 ， 技术团队做出了使用新技术架构、引入新技术 ， 以现有功能为主导作一次技术方案升级的决策 。
从背景中可以发现一个隐藏的条件 ， 技术重构是有前提的 ， 即产品是具有一定价值的 ， 是已经被用户和市场验证过的 ， 只是存在了不足和问题 ， 需要通过重构来解决
1. 技术重构的定义和原因
对技术重构做一个简单的定义：指代码重构 ， 通过代码重构来改善产品的性能 ， 使产品的设计模式和架构更加合理 ， 提高了扩展性和维护性 。
那技术重构的原因有什么呢？可以从业务和团队两个角度来看 。
1业务角度
业务体量的变化要求了产品需要进行技术重构 ， 不同的业务量级对技术方案的要求是不同的 ， 最简单的一个例子 ， 一款产品从MPV阶段到成熟阶段 ， 肯定会经历技术重构 ， MPV阶段用户体量小 ， 更注重的是验证功能的可行性 ， 这一阶段所选取的技术方案更侧重考虑快速性；而在成熟阶段 ， 用户体量大 ， 这个阶段就要求技术方案的稳定性 ， 以及所带来良好的用户体验
2团队角度
还可以从团队的角度来看是否需要进行技术重构 ， 当现有技术方案影响到了团队的效率时 ， 也会考虑进行新的技术方案替换和升级
【复盘，在技术重构中，产品需要做些什么呢】我司这款产品进行技术重构就有从团队角度的考虑 ， 从背景中可知原有的技术方案已经存在很久了 ， 一方面 ， 日常维护和处理线上问题时 ， 研发同学经常反馈代码的久远性导致需要花较多时间来定位和处理问题；另一方面 ， 日常迭代需求时 ， 产品提出的设计方案 ， 研发同学也反馈现有框架不支持一些交互 ， 导致方案妥协 ， 影响希望达到的预期效果
02 产品应该做什么？
【复盘，在技术重构中，产品需要做些什么呢】“技术重构”虽然是有技术团队驱动和主导的 ， 但是作为产品 ， 也需要我们做一些“正确”的事 ， 来帮助“技术重构”更好的完成 ， 具体的表现为：不随意增加新功能；梳理现有功能结构；思考未来功能需要的技术准备
1. 不随意增加新功能
技术重构是在原有功能的基础上进行的技术方案升级 ， “新功能”不属于技术重构的范畴 。 在技术重构的同时进行新功能迭代 ， 从“时间”和“成本”两个角度看 ， 是性价比极低的行为
1时间因素
技术重构的同时 ， 线上版本往往会保持“低频率”的迭代 ， 即以维护为主 ， 只迭代影响核心功能的紧急业务需求 。 这就要求了技术重构的周期在保持质量的同时可以尽可能的短 ， 因为即使线上版本保持了“低频率”的迭代模式 ， 但还是存在功能迭代的可能性 ， 拉长周期会导致重构结束后需要追的“需求”数量变多
增加新功能则会客观拉长了周期 ， 一起模拟一个案例 ， 有一款电商产品 ， 其交易模块是该产品的核心功能 ， 原计划该产品的重构周期是3个月 ， 但是因为加入了新功能导致重构周期扩展成了5个月 ， 线上版本在每个月都迭代了一个交易模块相关的功能 。 对比后就能很清楚的发现 ， “不增加新功能”重构完成后只需要追加3个功能 ， 而“增加新功能”则需要追加5个功能 ， 因此增加新功能是一件性价比低的决策 分页标题#e#
2成本因素
严格意义上 ， 技术重构对用户应该是无感的 ， 而增加新功能 ， 导致用户发现差异 ， 存在一定的解释成本 ， 如果增加的新功能数量很多 ， 甚至需要版本迁移的工作 ， 增加了成本 。 即使在一些特殊的技术重构中 ， 比如技术方案升级了前端组件的样式和交互 ， 对于用户来说也只是体验式的不同 ， 对于功能的实现度仍然是一致的
结合“时间”和“成本”的考虑 ， 得出一个结论 ， 在技术重构中 ， 增加新功能是性价比很低的行为
2. 梳理现有功能结构
在技术重构项目中 ， 也是一次产品很好的梳理现有功能结构的机会 ， 一方面可以帮助研发团队更明确哪些功能是产品的核心功能 ， 哪些功能是产品的次要功能 ， 可以更好的分配资源；另一方面可以找出现有功能中存在问题的模块 ， 并在本次重构中进行修复
1原有产品设计存在bug的功能
原有功能和最初产品设计方案存在出入的 ， 这一类功能传递给用户的信息并不是我们希望的 ， 不仅没有实现最初设计想解决某个问题的目的 ， 还可能成为用户产生“产品无法实现功能”甚至产生流失的定时炸弹 ， 而对于b端产品 ， 每流失一个用户都有可能会给公司带来不少的损失 。 对于这类功能 ， 就需要我们设计新的方案来更替原有的设计
案例：线上版本了通过“柱形图”来对比数据的功能 ， 用户可以选择字段 ， 通过柱形图来分析不同的数据差异情况 ， 但部分用户的团队人数很多 ， 数量变多后导致柱形图非常拥挤 ， 也没有办法观察出差异情况
调研用户的团队情况 ， 用户主要对比的场景时 ， 查看某一分组的（一般不超过50个人）最大值或者最小值部分 。 基于这个情况 ， 将原有的柱形图改变成直方图 ， 升序和降序的切换功能

文章图片

2原有产品设计影响效率的功能
产品功能实现了用户需求 ， 但是实现方式复杂 ， 增加了用户的操作成本 ， 这一类功能对用户效率产生了影响 ， 对于这一类功能也是需要我们重新设计替换的
案例：线上版本了过滤“指定消费者和聊天”产生行为数据的能力 ， 目的是为了不让一些特殊的消费者（例如刷单、广告等）数据对真实的团队数据产生影响 。 但是当前添加完指定消费者后 ， 表格是正序的 ， 虽然提示了添加成功 ， 但是不能很直观的从表格上看到添加后的数据 。 而更改排序规则后 ， 就能提升用户对于确认添加成功后的效率
这里我们可以得出一个结论 ， 在技术重构中 ， 我们可以对原有的产品进行梳理 ， 找到存在问题的功能和改动会明显提升效率的功能 ， 对这两者进行优化、修复、更替
3. 思考未来功能需要的技术准备
最后也需要我们产品思考未来迭代功能存在的可能性 ， 并及时的将这一可能性告诉研发团队 ， 以便于他们在技术方案设计的时候 ， 留下足够的空间或者提前做技术准备
案例：
某款产品正在进行技术重构 ， 存在一个问题：现有一级导航栏已经非常臃肿了 ， 想再加入新的导航菜单显得非常困难 ， 而后续还会有新的菜单加入的计划 ， 未来采取的做法是菜单会根据权重可配置展示、根据屏幕分辨率自适应 。 这就需要在本次技术重构中 ， 提前告知研发团队未来期望实现的 ， 那就可以提前将菜单不写死 ， 避免了菜单栏模块二次重构
总结
在面对技术重构类型的项目时 ， 产品也不是无所事事的 ， 需要我们帮助团队梳理原有的功能 ， 同时想清楚未来迭代的计划 ， 提前在技术方案升级时做好准备 ， 留下口子 。 只有做了应该做的事 ， 才不会影响团队的进度 ， 提升团队的效率 ， 避免出现二次重构
本文相关词条概念解析： 分页标题#e#
重构
重构（Refactoring）就是在不改变软件现有功能的基础上 ， 通过调整程序代码改善软件的质量、性能 ， 使其程序的设计模式和架构更趋合理 ， 提高软件的扩展性和维护性 。 对软件内部结构的一种调整,目的是在不改变"软件之可察行为"前提下,提高其可理解性,降低其修改成本 。

来源：(未知)

【】网址：/a/2020/0714/kd271649.html

标题：复盘，在技术重构中，产品需要做些什么呢