作为开发者，你应该很清楚在我们日常的工作中，需求文档是开发的基准，我们实现的也是需求中具体的内容。假设你的团队，为了解决业务组件跨项目复用的问题、提高业务的开发效率，选择要做自己的业务组件库。面对一个这样的需求，你会怎么做呢？
很多没有业务组件库组织经验的同学，一下就懵了，不知道从哪下手。为什么？因为"业务组件库"的需求，它没有太多的需求细节，你一眼看下去，它可能只有两个一级标题，"开发组件"以及"在项目中使用组件"，所以你不知道从哪下手是很正常的事情。不过也不要慌，你只要把需求明确，就有了一个好的开始。
怎么明确需求呢？你只要关注并清楚两个重点问题，一是业务组件库的定位及参与者，二是针对参与者，业务组件库需要提供哪些能力。下面我们来具体分析。
第一个问题：业务组件库的定位是什么？
定位有差异，做出来的产品就会有差异，就像我们要做一个商业产品，我们需要明白核心用户群是哪些人、业务模式是如何运转的等等，这些基础决定了我们后续具体要设计什么样的功能。但你可能会觉得对于业务组件库来说这个问题没什么好讨论的，它不就是前端团队为了管理公共业务组件而实现的工具嘛，可以提升我们的效率。但你知道吗？其实不同团队，甚至说同一团队在不同阶段，对业务组件库的定位都可能是有差异的，一般来说我们做业务组件库可能会有两种定位。
第一种比较简单，业务组件库可以做成纯前端的管理业务组件的工具，属于提效类的技术项目。项目的主要参与人是团队里的前端同学，同时也会找产品、设计同学寻求一些合作，比如确定一些实现的细节等等，最终前端同学把组件放入业务组件库中，后续在项目中直接复用组件即可。
第二种比较复杂，我们可以把它做成产品研发体系下所有人都会参与建设的标准化组件体系，属于标准化的综合性项目。项目的主要参与人就变成了设计同学、产品同学和前端同学。产品、设计同学在前期确定组件的表现形式，前端同学负责实现，放入业务组件库。之后产品、设计同学设计需求时就可以按照实现好的标准组件进行设计，业务实现的时候直接复用组件即可。整个体系正向循环往复，成为产品、设计、实现层面的标准和基石，整体的业务支持效率就会越来越高。
这两种定位在技术实现层面上差异不大，主要影响的是参与角色、流程的管理等等纯项目层面的问题，你可以根据团队的实际情况进行选择，想清楚之后我们就可以来考虑具体需求了。
第二个问题：需要给业务组件库的参与者提供哪些能力？
因为组件库比较复杂，需求点很多，这个时候如果直接开始考虑一个一个需求点的话很容易迷失在细节中，给你提供一个简单的方法：找入口。在前面定位明确了之后，参与的角色也就定下来了，我们来考虑一下针对这些参与的角色，业务组件库需要提供哪些能力，这些能力其实就是我们要实现的核心需求。
我们先从会在业务项目中使用组件的同学看起，他们的诉求无非是两点，使用方便、使用安全。从方便的角度来说，我们需要保证组件的抽象设计合理，需要提供一个方便的文档服务，并且还要保证单个组件的文档完整清晰（API 清晰、示例清晰）；从安全的角度来说，我们需要从根上保证组件的实现质量，还需要提供组件的兼容性信息、测试的情况，并且还要讲清楚组件的升级迭代流程，让使用者不会有使用上的焦虑感。
再看一下产品、设计同学，前面也提到我们需要与他们合作，因为他们对前端的实现没那么了解，所以需要我们提供他们能看懂、会用的相关产品，比如说最基本的文档服务，他们可以通过文档明确我们已经有哪些组件，每个组件可以支持什么功能，再比如说如果要搭建标准化的组件体系，我们需要提供他们在用的原型设计工具、UI 设计工具的配套插件等等。
最后再看一下组件的开发者，一方面要降低他们的开发成本，方便的在体系中开发组件，比如说配套的开发工具。另一方面要调动团队成员的积极性，积极贡献组件，这就需要我们学会"运营"组件库，往往我们研发同学是不太擅长这个方向的，所以可能需要团队成员一起集思广益。
从给参与角色提供的能力出发，我们就可以想到以上种种需要提供的能力，总结一下可以分为以下四个维度：
组件开发：提供代码开发、构建的能力，有保障组件实现质量的能力；
组件使用：提供组件文档，提供产品、设计同学生产力工具的插件；
流程规范：提供组件开发、迭代、升级的流程规范，提供代码设计、实现、review 阶段的规范，提供文档撰写的规范；
运营：提供运营业务组件库的方法。
这个时候相当于大的模块已经确定下来了，我们再看业务组件库需求就清晰很多了，后面再去填具体的细节就可以了。
总结
OK，通过对以上这两个问题的思考，我们相当于明确了业务组件库需求的主体脉络，就像把整个需求文档的一级标题、二级标题，甚至是三级标题都确定了下来。这个时候你再想一下，一开始那种不知道从哪里下手的感觉还在吗？应该好很多了吧。
面对这种复杂的工程化问题，我们一定不能一上来就考虑实现的细节，然后搜索具体的解决方案。作为开发者你应该明白，一些复杂的综合性的问题是没有办法直接搜到解决方案的，胡乱搜索只能是浪费时间。这里要做的就是"拆"，把复杂的问题还原成一个一个独立的、核心的、相对简单的问题，然后再去寻找这些问题的解决方案。这是我们面对复杂问题的解决方法，同样适用于业务组件库这个命题。
在这节课的最后，我想再跟你分享一些比较容易忽略的点。
第一个是保障组件实现质量的能力。组件开发完成之后不可能立刻在项目中使用，使用组件的同学一定会担心组件的实现质量，包括代码质量，以及后续迭代升级的时候对项目会不会有影响等等，这一点很容易被忽略，所以我们要想办法消除他们的顾虑。
第二个是流程规范。如果从组件的完整生命周期出发，它要经过非常多的环节，涉及到的规范会有很多，我建议如果时间允许的话，越早考虑规范的事情越合适，详细的内容可以关注我之后要讲的"业务组件库的规范体系设计"。
第三个是"运营"业务组件库，前面也提到了，这个对我们来说比较难，需要团队成员一起集思广益，这一点容易忽略，所以早一点开始想是有非常大的好处的。在我们贝壳交易前端团队中，是怎么运营业务组件库的呢？为了提升组件开发者的成就感，我们在单个组件的文档底部标注了贡献者的名字、展示该组件的使用数据。为了增加其他同学对已经完成组件的了解，我们会在团队例会中有发布组件的环节，在相关群里组织"每日精选组件"推荐等等。你如果有其它好的运营方式也欢迎在评论区提出。