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

但是，这个组件设计成这样，它就基本只适合用在评论功能里，它可以用在不同业务的评论功能里，但你不会直接用它来展示一个社交软件里用户曾经写过的话，不会的。
所以，跟着特定业务场景走的组件，叫做业务组件。
搞清楚了这个概念，接下来我就可以得到有哪些组件了。

文章插图
四、流程设计到这里，我们只是完成了概念设计。
就像拼积木一样，我们把积木的碎片设计好了，但是要怎么搭建，需要用一步步的操作把积木串联起来。因此，在项目方案设计中，接下来最重要的是流程设计。
流程设计只解决一个问题：一个业务要用你的组件，它该怎么做。
再回到我们的比喻，我们当然希望，如果我们需要一个「超人」，那你给我碎片就好，我手动搭建起来。
但事实上，如果要实现100%的无代码接入，也就是只需要配置配置就好，完全没有任何开发成本，那这样的设计对于系统本身的开发复杂度要求非常高。
所以从成本和适用性的角度考虑，低代码量级的接入是一个更合适的选择。以前需要一周完成的事情，我现在可能只需要4个小时，那这就是成本的极大节约。
而对业务接入做管理设计，则需要做抽象。抽象什么呢？
管理要素。
我们的社会之所以可以正常运转，是因为在复杂的社会生态下，有不同的管理单元在运行着。比如厅、局、科；比如校、班、组。
合理地划分管理单元，并分而治之，便是对业务接入做管理设计的核心。
我们的评论功能可以拆分为三个管理层次：业务、应用和内容。
业务：所有需要用到评论功能的业务方，可以看作一个独立的业务单元。它可能是跟着组织架构走的，也可能是跟着产品模块走的，甚至是一个活动虚拟组织。
只要你觉得，这个业务后续需要有一套独立的管理权限和配套设施（也就是我们的配置能力），那它就可以独立成为一个业务。
业务是提前定义好的，这就要求产品经理在设计时做好沟通，知道现在以及将来，已经有并可能有哪些业务会用到你的系统。
应用：一个业务使用某个组件，我叫做一个应用。
比如当我接入一个新业务时，我就默认给这个业务创建了6个组件应用，每个组件应用可以单独配置，他们组合起来，就是这个业务最终在评论功能上所有的功能特性了。
内容：对评论组件来说，最终的管理颗粒度是要细化到每条评论，包括：增、改（改不是改内容，而是改属性，比如打标）、删、查、审、导出等。
只有精细到每一条评论的管理粒度，才能最大程度上满足业务的诉求。
做完业务管理，基本所有结构层面的方案设计，就全部结束了。接下来就是更细化的展示和体验，这个就靠跟UI的沟通和配合了。
五、总结总体来说，虽然「评论组件化」对我来说是一个完全陌生的项目，而且面临着时间紧、任务重的巨大挑战，但我还是觉得有一些方法和新的可以分享给大家，无论是之后做组件化，还是突然面临一个复杂的系统任务，我觉得都可以参考：
1）了解why和why now。复杂的事情，如果需要消耗你巨大的精力，一定要去理解，为什么要做，为什么要现在做，驱动力的问题，怎么想都不过分。
2）通过大量的观察和体验，找到复杂多元的外表下，那些核心的不变的要素。跟着那些要素再回过头去看产品，如果你可以建立一个模型，当你做任意输入时，都能预料到输出，代表你就彻底掌握了。比如删除评论，回复还在不在。在没有研究这个问题时，我很少会注意到这个规律。