模块化、组件化与插件化(1)

模块化、组件化与插件化

•   组件化 modularization、component
  

•   模块化 modularization
  

•   插件 plug-in；plug-in component；plug-in module
  

什么是组件化modularization？ 将一部分业务代码从主工程独立出去，单独编译运行，最后再合并测试并发布的方案得到广泛运用。这就是组件化

1.实际项目中的组件化问题

• 解决人多（更好的协作）、需求多（更好的功能模块划分）的问题；
• 解决项目模块间的代码耦合问题；（坚决抵制业务组件间代码直接引用）

产品业务组件：（例如圈子、1元购、登录、客服MM等）

• 业务功能间相对独立，相互间没有Model共享的依赖；
• 业务之间的页面调用只能通过UIBus进行跳转；
• 业务之间的逻辑Action调用只能通过服务提供；

在组件化 / 模块化之前，蜂鸟商家版 App 的所有代码 / 资源文件等都是在同一个主工程里的，只有 RN 仓库或组内公用私有库等极少部分代码游离于主工程之外，所以在开发时，每一次都要编译整个项目的所有代码，十分低效。这个问题在独立开发时还不是十分明显，毕竟虽然项目大但是代码只有一个人在提交，所以项目代码量增加也不是那么夸张而且对项目发生的变化比较熟悉。但是当多人协作开发时，这个缺陷就暴露了出来，大家在各自开发不同的业务时，不仅要时刻和他人同步项目变化、读懂他人代码，还要每次编译完整个项目才能对自己所做的一点修改进行调试，效率低下。

• 项目臃肿不堪
• 团队规模变化
• 业务发展压力
• 代码管理混乱

目标

• 加快编译速度，不用再编译组件 / 模块外没有被依赖到的代码；
• 便于将每个模块指定给不同负责人进行管理；
• 降低合并难度，减小冲突和出错概率，提高业务开发效率；
• 将 Swift 和 OC 代码进行分离，便于进一步 Swift 化工作的推进；
• 可为模块编写单元测试，提高工作效率，同时方便测试人员进行有针对性的测试。

目标设定

• 功能组件独立：保证所有的底层功能组件从主工程抽出，独立与主工程之外，便于复用、业务模块的调用；
• 业务模块划分与拆解：将业务按对应用途进行划分和拆解，想办法切断各业务之间的强依赖；
• 所有组件 / 模块独立编译：所有功能组件和业务模块能够独立于主工程进行编译，有各自的 Demo 工程；
• CocoaPods 发布：在内网 GitLab 进行发布，并且之后对每个模块用 GitFlow 工作流进行管理和后续发布工作。

三. 计划制定

组件，就是我们对功能的封装，一个功能就是一个组件，数据库、网络、文件操作、社会化分享等等这些功能都是组件。我们之所以要搞出组件的概念，是为了能够让我们的上层业务模块能够随时依赖和调用这些基础功能。组件基本上可以分为基础功能组件、通用 UI 组件、基础业务组件等这几类。所以为了满足上述要求，组件必须具有较高的独立性、扩展性以及复用性。

模块，就是对一系列有内聚性的业务进行整理，将其与其它业务进行切割、拆分，从主工程或原所在位置抽离为一个相对独立的部分。仅仅针对业务而言，比如说我们可以把订单业务独立为为一个模块，可以把个人中心独立为一个模块，把用户登录独立为一个模块等，在 App 中的体现就是一个个独立的 Git 仓库。模块化的一个好处是用到时可以搭积木，比如可以多个工程间复用同一个或几个业务模块，比如腾讯的 QQ 和 TIM，除了 UI 界面外 TIM 显然复用了大量现有的原 QQ 工程的业务模块代码，当然，我们这里暂时并没有这个需求。

1. E1‡.png

Pasted Graphic 2.png

看了这篇文章会给很多启发,明白了很多东西
http://www.cocoachina.com/articles/21967

模块与组件

在一个项目中

个人理解

组件可以组成一个模块

模块之间进行相互跳转


模块化开发：按照项目业务模块来划分，将一个app按业务拆分为登
录模块、聊天模块等等，模块化其中一个核心的目的就是代码的高可
复用、高可维护和高可扩展性能。

组件化开发：对应用功能的封装，一个功能一个组件。比如网络连接
交互组件、即时通讯IM组件、数据库组件等。是对模块化更小的细
分。

最后总结一下
我认为 组件化 还是模块化
因为项目开发的人数比较多,功能大多比较杂
因此基础的东西 或者 模块做成pod当时引入 最为简单
但是要做成什么样的 几个模块如何互调?是做成pod引入么? 下次再看看