富交互产品的困境

最近半年、主要聚焦在两个典型“富交互”产品的开发，一个是「架构图设计器」、一个是「日志文档」，虽然也都发布到了线上，但平心而论、产品体验以及发挥的作用都不够好。反思下、抛开诸多“客观因素”，最大问题是自己一开始没有「真正」领会到这类产品巨大的 开发成本和潜藏的复杂度、及其在业务中链路起到多大的作用。这里从后一个日志产品 0-1 的过程，做一下比较详细的回顾总结。

时间节点：

• 12.10 交互稿+功能评审: 后端“逻辑细节”是重点；前端只能感知到大的模块、判断能不能做。
• 12.15 视觉稿+细节评审: 后端“更加细化”出接口；前端细化功能点、产出“系分+粗略估时”。
• 12.18 产出 API 文档(前后端)；前端“应用名、代码模块/组件抽象、mock 数据”等初步工作。
• 12.28 经过 12h x 6d 的全时投入开发、堆完了主要功能点(上日常)，但“前端功能链路”未完全通顺、代码“基础架构”有漏洞。
• 12.31 新增两位同学共投入 8h x 2d 支援“头像、点赞、自动保存、局部模板”几个独立功能。
• 2021.1.5 主链路功能顺畅、底层架构更优、视觉还原度接近高保真版本。但仍有重要细节问题、bug 等。
• 2021.1.29 完成“富文本编辑器”、“移动端读的适配”、“选用户组”、“数据重复”、“体验细节进一步优化”等新的功能点或优化点。

细节拆解：

• 显然的：
  • 联动筛选、列表分页、头像、已读未读/点赞/删除/修改；增删改/排序、多种模板、多种状态。
  • 接口个数 30+，依赖三方工具库 5+，实际代码 5000+ 行、改动代码 1000+ 行（手写/非生成/非三方）。
• 三方的：
  • 接口联调、环境部署、依赖三方组件问题、代码被改坏、测试问题和 edge-case。
  • 产品细节要求高 & 认为的完成度(视觉还原/交互细节)不一样 & 未明确的功能点。
• 复杂的：
  • 搜索->选择项目->查任务；弹窗的触发条件、位置。
  • 富文本工具栏、特殊字符、图片上传。自动保存、数据重复。
• 困难的：
  • 六层(tpls -> pages -> nodes -> sections -> tasks -> extInfo)嵌套的数据结构；
  • 数据关联：tplID_pageID_sectionID 标记为全局 projID 传给其他 sections -> tasks projId 变动后需再刷新数据；
  • 数据状态：“初始态、编辑态、提交态” 跨态部分同步、部分修改；
  • 数据与事件：既有耦合又有分离，不能完全数据驱动。
  • 架构的 “思考和设计 & 重构优化 & 踩坑” 成本。
• 举例：
  • 带搜索的 TODO-list，可以加自定义 todo、也可以从搜索结果的 list 里选一个、但需要把“已选”的 todo、从搜索结果排除掉。
  • 添加大模块、添加事项，有编程或点按钮方式、结果都是改变全局 pageData，怎么确定“只是”通过按钮触发？并且在 setPageData hooks 设置成功> 后？再保存到服务端。
  • 几乎「同时」多次提交数据、后端处理是否有问题？
  • 在列表项有“移动/增删”时，确保手动维护好 react key，并且持续唯一。
  • react hooks 模式下同一 state 在 visibilitychange 事件和正常数据流 结果不一致。
  • 性能和体验：一次性添加多个事项，需要多个“富文本实例”初始化、同时发送多个请求，导致页面卡顿。

从以上细节描述中不难看出，开发时间非常紧张(但这大概是所有项目共性)、交互复杂度高(虽然最复杂的编辑器还是三方组件)，最终也导致了进度延期(其实是最初时间评估不合理)。

我们知道“开发全过程”就像画画(轮廓-线条-着色)、对应几个不同阶段，“POC”版本(主功能跑通/打牢基础) -> “低保真”版本(全功能跑通/交互视觉大致完善) -> “高保真”版本 -> 最终版本，阶段之间也难免有额外时间损耗。

大阶段内的工作再细化后，就能大致总结出一个公式: 总工作量(时间) ~= 业务功能点数量 x 单位工作量(时间)，其中 “业务功能点数量 ~= 数据操作个数(增删改查)”，“单位工作量 ~= 复杂度(复用点/细节点/难点/未知点/维护难度)”。

也能据此公式区分出产品的 “简单与复杂”：

• 简单产品 (展示类 线性流程类控制台):
  • 复用点多(三方组件多+少量定制)，细节点少(简洁操作&输入)，难点少(数据结构简单/架构简单)，维护难度小。
• 复杂产品 (编辑器 设计器 游戏):
  • 复用点少(三方组件少)，细节点多(复杂操作&模块间大量级联&关联)，难点多(数据组织难/架构复杂)
  • 未知点多(很多“功能点/优化点”、测试或使用过程中才暴露出来)。
  • 维护难度大(关键代码影响重大、可能只是改动几行但要花很多时间；需要持续打磨优化)。

以上看到 “复杂产品” 大多都是专业性很强的“垂直”产品，偏“工具”性质、容易被替代，解决的是常见业务链路里的“单点”需求/问题。开发过程中有「大量耗时」的复杂点，导致产出“速度慢”、成果“不明显”；并不是上线就结束、而往往是漫长维护和优化的开始。另外因为真正对这些复杂点有经验的人又很少、不明真相的就肯定会疑问：这明明看起来不麻烦、怎么花这么多时间？缺乏真正的同理心。而在业务团队里，大多是讲究 “短平快”/“快速拿结果”，做这些很容易就吃力不讨好了。

总结

富交互产品的困境在哪儿？在于“富交互”产生了高成本，但带来的价值究竟有多大？值不值得投入，适合什么样的团队投入？却没有明确的答案。于个人而言，从 4 月初开始做的「架构图设计器」到最近一个多月做的「日志文档」这两个富交互产品(期间对团队其他产品也临时支持时间一个多月)，导致自己是每天 11~12h 的满负荷工作，身心俱疲、头也常常蒙蒙作痛。当然也正是这从未有过的这么痛的经历后、才『真正』体验到了这类产品的巨大潜藏成本，然而这就是仅有的“收获”吗？