「评论功能组件化」实践分享

很长时间以来，我的工作都是一名偏向业务的产品经理。我的职责是帮助对接的业务实现更好的业务增长，这里的增长不仅包括收入的增长，也包括成本的降低。

但我很少有机会去做一名中台产品经理，以更抽象的视角去规划各个业务都会用到的核心功能。

虽然我一直都明白中台产品经理的职责是什么，但没有什么机会去实践。而我相信，一件事情做过还是没有做过，认识是完全不一样的。

所以去年年底的时候，老板说让我去负责「评论组件化」这个项目，我意识到这是一次实现自我突破的好机会。因为这对我来说是一次巨大的挑战，我之前从未负责过类似的产品。

现在，三周过去了，我也从最初毫无逻辑，到完成了整个方案的评审，一路走来感慨颇多。即骄傲于自己在三周内完成了方案的输出和评审，也谦卑于对于未知的世界，站在里面和站在外面，看到的东西有多么的不一样。

于是决定将这三周的实操经验分享出来，供更多从业务走向中台的产品经理参考。

一

对我来说，当我知道一件事情将要花去我很多的精力时，我一定要搞清楚两件事：

1、这件事为什么要做

2、这件事为什么现在就要做

在解释为什么要做「评论组件化」这件事之前，我首先想跟大家解释一下这个项目是什么。

大家如果玩过积木就知道，当我们想要一个成型的具体的玩具时，我们可以用积木去拼出来。对于积木来说，它的生产过程就只有每一个碎片，当它出厂之后，就不再有生产成本了。购买的人想要什么东西，就自己拼就好。

对于一个功能也是这样，它是像积木一样由已有的模块拼起来的，还是说是在工厂里从0到1生产出来的，背后的成本是完全不一样的。

因为一些历史原因，很长时间以来，我们公司的各个业务都是并行发展的，即便是一些相同的功能，也因为各个业务诉求不一样，最终是由各业务的产品经理独立设计。

评论功能就是这样。

虽然我们的app主要是一个听书产品，但我们还是有多个独立的业务，并且在当前阶段都有独立的产品模块。评论功能就是这些业务都具备的一个功能，但长期以来都是独立开发的。

于是这就导致几个很严重的问题：

第一，开发资源的重复投入。

一个业务的评论功能，并不能立刻在另一个业务上复用，每做一个新业务，都需要从头开发。有产品经理可能会问，这有什么难的，你照着其他业务的代码再写一份不就可以了么？

但你要知道，再简单的评论功能也包括底层数据、客户端样式和管理后台，即使有代码可以抄，那开发和测试的边际成本也是非常高的，更不用说各个业务是否能100%复制还不一定。

第二，用户体验不一致。

因为是独立开发，每个产品经理都有自己的想法，且一条业务的产品经理很多时候还是流动的，因此最终呈现出来的功能有很多细节处的细小差异。

但用户访问的是同一个app，有时候这些细节上的差异，会带来体验不一致性，而这个，有时候会导致非常糟糕的用户体验。

第三，信息差导致好的方案不能共享。

实际情况下，很少有业务方会去研究其他业务方现在用的比较好的功能有哪些，甚至一个业务方觉得很稀松平常的功能，在另一个业务方眼里就是特别好的功能。

因此这样普遍存在的信息差，会导致即使局部最优无法实现整体最优，功能本身积累的势能无法最大程度的释放出来。

那为什么要现在做呢？

「功能组件化」这件事是有时间窗口的，做早了或者做晚了，都不合适。

从乐高的比喻比喻中你可以想象，如果我要的是一个「超人」，你给我一堆碎片，让我自己拼。那么这一定是浪费效率的，可能不如给我一个「超人」来得快。

所以如果「功能组件化」这件事做早了，那么对业务来说就是「杀鸡用了牛刀」，性价比划不来。

但另一方面，如果这件事做晚了会如何？

从系统角度来说，就会严重增加后续组件化的成本。因为每一个业务都在自己的系统里将同一个功能做了不同方向的演化，所以后续要统一管理时，改造难度很大。

就好像城市改造，如果当初都是各个小区各自规划，后续要拆迁翻新，统一治理时，成本是非常大的。

因此，从时机上，组件化这件事是要做的，而且是值得现在就投入精力去做的。

二

认识到这个问题，我就在想，最核心的问题到底是什么。

我们前面说到，任何一个业务的评论功能，基本都具备底层数据管理、客户端样式和内容管理后台，那最核心的问题到底是什么呢。

为此，我去体验了我手机上所有app的评论功能，无论是写，还是评论，还是删除，我发现在五花八门的外表之下，只有一个点具备了惊人的一致性。

那就是「对象-评论-回复」这三个角色。

对象，是指对什么内容所做的评论；

回复，是指对其他人贡献的内容所做的回复。

围绕评论，我们一定能抽象出对象和回复这两个概念，并且这三个概念在几乎所有带评论功能的产品里都能找到。

所以，我把最核心的问题定义为：找到我们自己app里的「对象-评论-回复」分别是什么。

在这个基础上，我可以再去定义底层的数据结构了，他们呈现出如下的树状结构

这时候大家就会发现，如果我把对象去掉了，那所有的评论其实也就没有了，同理，如果我把某个评论删除了，它下面的回复也就没有了。

但另一方面，我如果删除了回复一，其实不影响回复二和其他的回复。

这个规律准么？大家可以试试发一条朋友圈，然后评论，然后删除；或者发一条微博，然后评论、回复、删除，你就能发现规律了。

顺便说一句，朋友圈的结构比这个更简单，对象下面的评论和回复都在一级，删除评论，对应的回复也还在。看到这里的时候，我感叹张小龙设计结构时的简约。

三

数据结构定义好了，接下来就该去抽象组件了。

在这一步上，我特别感想研发同学对我的帮助。因为组件是一个技术语言，只是因为要做这件事，所以用在了产品上。

但从技术的角度来说，组件又包括功能组件和业务组件。他们两者是完全不同的。

对于功能组件来说，它聚焦于跟功能绑定。

比如文本输入是一个功能组件，无论是评论功能，还是UGC创作，甚至是社交软件的聊天功能，凡是需要用户自己产生内容的地方，都会用到文本输入。这就是一个典型的功能组件。

但业务组件是跟着业务走的，比如下面这张图。

从抽象的角度来说，这张图代表着展示一个用户在什么时间写了什么内容，并且针对这个内容还打标了，还能进行一系列操作。

但是，这个组件设计成这样，它就基本只适合用在评论功能里，它可以用在不同业务的评论功能里，但你不会直接用它来展示一个社交软件里用户曾经写过的话，不会的。

所以，跟着特定业务场景走的组件，叫做业务组件。

搞清楚了这个概念，接下来我就可以得到有哪些组件了。

组件	属性	解释
评论列表	业务组件	代表一个资源下有多个评论做聚合时的特性
评论详情	业务组件	代表一个评论下有多个回复做聚合时的特性
文本输入	功能组件	代表文本输入的交互，可用在评论功能里，也可以用在其他地方
文本操作	功能组件	代表长按、轻按文本时的操作，可用在评论功能里，也可以用在其他地方
评论分享	业务组件	代表一个评论或回复被分享时的特性
评论聚合	业务组件	代表一个用户下有多个评论做聚合时的特性

四

到这里，我们只是完成了概念设计。

就像拼积木一样，我们把积木的碎片设计好了，但是要怎么搭建，需要用一步步的操作把积木串联起来。因此，在项目方案设计中，接下来最重要的是流程设计。

流程设计只解决一个问题：一个业务要用你的组件，它该怎么做。

再回到我们的比喻，我们当然希望，如果我们需要一个「超人」，那你给我碎片就好，我手动搭建起来。

但事实上，如果要实现100%的无代码接入，也就是只需要配置配置就好，完全没有任何开发成本，那这样的设计对于系统本身的开发复杂度要求非常高。

所以从成本和适用性的角度考虑，低代码量级的接入是一个更合适的选择。以前需要一周完成的事情，我现在可能只需要4个小时，那这就是成本的极大节约。

而对业务接入做管理设计，则需要做抽象。抽象什么呢？

管理要素。

我们的社会之所以可以正常运转，是因为在复杂的社会生态下，有不同的管理单元在运行着。比如厅、局、科；比如校、班、组。

合理地划分管理单元，并分而治之，便是对业务接入做管理设计的核心。

我们的评论功能可以拆分为三个管理层次：业务、应用和内容。

业务：所有需要用到评论功能的业务方，可以看作一个独立的业务单元。它可能是跟着组织架构走的，也可能是跟着产品模块走的，甚至是一个活动虚拟组织。

只要你觉得，这个业务后续需要有一套独立的管理权限和配套设施（也就是我们的配置能力），那它就可以独立成为一个业务。

业务是提前定义好的，这就要求产品经理在设计时做好沟通，知道现在以及将来，已经有并可能有哪些业务会用到你的系统。

应用：一个业务使用某个组件，我叫做一个应用。

比如当我接入一个新业务时，我就默认给这个业务创建了6个组件应用，每个组件应用可以单独配置，他们组合起来，就是这个业务最终在评论功能上所有的功能特性了。

内容：对评论组件来说，最终的管理颗粒度是要细化到每条评论，包括：增、改（改不是改内容，而是改属性，比如打标）、删、查、审、导出等。

只有精细到每一条评论的管理粒度，才能最大程度上满足业务的诉求。

做完业务管理，基本所有结构层面的方案设计，就全部结束了。接下来就是更细化的展示和体验，这个就靠跟UI的沟通和配合了。

五

总体来说，虽然「评论组件化」对我来说是一个完全陌生的项目，而且面临着时间紧、任务重的巨大挑战，但我还是觉得有一些方法和新的可以分享给大家，无论是之后做组件化，还是突然面临一个复杂的系统任务，我觉得都可以参考：

1）了解why和why now。复杂的事情，如果需要消耗你巨大的精力，一定要去理解，为什么要做，为什么要现在做，驱动力的问题，怎么想都不过分。

2）通过大量的观察和体验，找到复杂多元的外表下，那些核心的不变的要素。跟着那些要素再回过头去看产品，如果你可以建立一个模型，当你做任意输入时，都能预料到输出，代表你就彻底掌握了。比如删除评论，回复还在不在。在没有研究这个问题时，我很少会注意到这个规律。

3）找到最原始的概念。我们可能会用到很多抽象的概念，以及基于这些概念衍生出来的二级概念，如果我们一开始理解的不是最原始的意思，很可能就容易走歪。其实我一开始并没有很好的理解功能组件和业务组件，直到技术leader跟我讲了一晚上，我才逐渐理解。特别感谢他。

4）确定管理颗粒度。系统一定是有管控单位的，比如课程管控的是节目，讲书管控的是书籍，公司管控的是员工，学校管控的是学生。找到你的系统的管理粒度，会让你在系统设计上，跟核心要素产生更好的连接。

完