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

因此这样普遍存在的信息差，会导致即使局部最优无法实现整体最优，功能本身积累的势能无法最大程度的释放出来。
那为什么要现在做呢？
「功能组件化」这件事是有时间窗口的，做早了或者做晚了，都不合适。
从乐高的比喻比喻中你可以想象，如果我要的是一个「超人」，你给我一堆碎片，让我自己拼。那么这一定是浪费效率的，可能不如给我一个「超人」来得快。
所以如果「功能组件化」这件事做早了，那么对业务来说就是「杀鸡用了牛刀」，性价比划不来。
但另一方面，如果这件事做晚了会如何？
从系统角度来说，就会严重增加后续组件化的成本。因为每一个业务都在自己的系统里将同一个功能做了不同方向的演化，所以后续要统一管理时，改造难度很大。
就好像城市改造，如果当初都是各个小区各自规划，后续要拆迁翻新，统一治理时，成本是非常大的。
因此，从时机上，组件化这件事是要做的，而且是值得现在就投入精力去做的。
二、核心问题是什么认识到这个问题，我就在想，最核心的问题到底是什么。
【经理|「评论功能组件化」实践分享】我们前面说到，任何一个业务的评论功能，基本都具备底层数据管理、客户端样式和内容管理后台，那最核心的问题到底是什么呢。
为此，我去体验了我手机上所有app的评论功能，无论是写，还是评论，还是删除，我发现在五花八门的外表之下，只有一个点具备了惊人的一致性。
那就是「对象-评论-回复」这三个角色。
对象，是指对什么内容所做的评论；
回复，是指对其他人贡献的内容所做的回复。
围绕评论，我们一定能抽象出对象和回复这两个概念，并且这三个概念在几乎所有带评论功能的产品里都能找到。
所以，我把最核心的问题定义为：找到我们自己app里的「对象-评论-回复」分别是什么。
在这个基础上，我可以再去定义底层的数据结构了，他们呈现出如下的树状结构

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

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