创建CBB心得_逻辑cbb

本文来和大家分享制作 CBB 公共组件的一些心得

在创建 CBB 的时候的两个核心问题是：让开发者开发的开森；让使用方使用的开森。前者就是本文的讨论内容，后者基本都是靠 API 设计

让开发者开发得开森，就涉及到开发策略的不同

在创建 CBB 的时候我尝试有两个不同的策略，本文将和大家讨论使用这两个不同的策略在开发效率以及 CBB 推动上的不同差别

下面先来和大家聊聊这两个不同的策略

第一个策略是在创建的 CBB 独立仓库项目里面进行开发，然后开发完成之后再进行项目的接入

第二个策略是在具体的项目里面开发，在开发完成发布之后，再将逻辑抽取为公共组件，放在公共组件仓库

采用这两个策略不意味着从始至终都需要采用某个策略，可以灵活根据需求在开发过程中进行切换。接下来讨论这两个策略的优缺点

第一个策略在独立的仓库项目开发，此时为了确定功能，大部分都是需要通过额外的 demo 以及单元测试的辅助。因为是放在独立的仓库里面，也就很难会耦合业务，也不会耦合具体某个项目的功能，做出来的功能相对通用。而且调试起来很轻，不需要加载具体的大项目，只需要跑起来 demo 即可。而在此过程，可以愉快添加更多的单元测试，用于多个入口的进入。而这些 demo 和单元测试，在开发完成之后，可以反馈给后续的维护阶段，在维护阶段中，可以用上这些 demo 和单元测试来提升维护的效率。使用策略一可以脱离业务端进行开发，可以编写出覆盖更多的范围的测试用例而不会被限制到具体项目的某些业务上，对于其他项目的接入会更友好

但是也因为第一个策略是在独立的仓库项目开发，因此大部分的我的这些项目都会在经过一段时间开发之后，再接入具体项目时，出现了业务需求的不匹配，或者 A