经理|「评论功能组件化」实践分享( 二 )

因此，从时机上，组件化这件事是要做的，而且是值得现在就投入精力去做的。
二、核心问题是什么认识到这个问题，我就在想，最核心的问题到底是什么。
我们前面说到，任何一个业务的评论功能，基本都具备底层数据管理、客户端样式和内容管理后台，那最核心的问题到底是什么呢。
为此，我去体验了我手机上所有app的评论功能，无论是写，还是评论，还是删除，我发现在五花八门的外表之下，只有一个点具备了惊人的一致性。
那就是「对象-评论-回复」这三个角色。
对象，是指对什么内容所做的评论；
回复，是指对其他人贡献的内容所做的回复。
围绕评论，我们一定能抽象出对象和回复这两个概念，并且这三个概念在几乎所有带评论功能的产品里都能找到。
所以，我把最核心的问题定义为：找到我们自己app里的「对象-评论-回复」分别是什么。
在这个基础上，我可以再去定义底层的数据结构了，他们呈现出如下的树状结构

文章插图
这时候大家就会发现，如果我把对象去掉了，那所有的评论其实也就没有了，同理，如果我把某个评论删除了，它下面的回复也就没有了。
但另一方面，我如果删除了回复一，其实不影响回复二和其他的回复。
这个规律准么？大家可以试试发一条朋友圈，然后评论，然后删除；或者发一条微博，然后评论、回复、删除，你就能发现规律了。
顺便说一句，朋友圈的结构比这个更简单，对象下面的评论和回复都在一级，删除评论，对应的回复也还在。看到这里的时候，我感叹张小龙设计结构时的简约。
三、抽象组件数据结构定义好了，接下来就该去抽象组件了。
在这一步上，我特别感想研发同学对我的帮助。因为组件是一个技术语言，只是因为要做这件事，所以用在了产品上。
但从技术的角度来说，组件又包括功能组件和业务组件。他们两者是完全不同的。
对于功能组件来说，它聚焦于跟功能绑定。
比如文本输入是一个功能组件，无论是评论功能，还是UGC创作，甚至是社交软件的聊天功能，凡是需要用户自己产生内容的地方，都会用到文本输入。这就是一个典型的功能组件。
但业务组件是跟着业务走的，比如下面这张图。

文章插图
从抽象的角度来说，这张图代表着展示一个用户在什么时间写了什么内容，并且针对这个内容还打标了，还能进行一系列操作。
但是，这个组件设计成这样，它就基本只适合用在评论功能里，它可以用在不同业务的评论功能里，但你不会直接用它来展示一个社交软件里用户曾经写过的话，不会的。
所以，跟着特定业务场景走的组件，叫做业务组件。
搞清楚了这个概念，接下来我就可以得到有哪些组件了。

文章插图
四、流程设计到这里，我们只是完成了概念设计。
【 经理|「评论功能组件化」实践分享】就像拼积木一样，我们把积木的碎片设计好了，但是要怎么搭建，需要用一步步的操作把积木串联起来。因此，在项目方案设计中，接下来最重要的是流程设计。
流程设计只解决一个问题：一个业务要用你的组件，它该怎么做。
再回到我们的比喻，我们当然希望，如果我们需要一个「超人」，那你给我碎片就好，我手动搭建起来。
但事实上，如果要实现100%的无代码接入，也就是只需要配置配置就好，完全没有任何开发成本，那这样的设计对于系统本身的开发复杂度要求非常高。
所以从成本和适用性的角度考虑，低代码量级的接入是一个更合适的选择。以前需要一周完成的事情，我现在可能只需要4个小时，那这就是成本的极大节约。
而对业务接入做管理设计，则需要做抽象。抽象什么呢？
管理要素。
我们的社会之所以可以正常运转，是因为在复杂的社会生态下，有不同的管理单元在运行着。比如厅、局、科；比如校、班、组。
合理地划分管理单元，并分而治之，便是对业务接入做管理设计的核心。
我们的评论功能可以拆分为三个管理层次：业务、应用和内容。
业务：所有需要用到评论功能的业务方，可以看作一个独立的业务单元。它可能是跟着组织架构走的，也可能是跟着产品模块走的，甚至是一个活动虚拟组织。