组件化开发之-我们有什么必要使用组件化开发？

原创 2016-05-19

背景介绍：
首先简单说一下为什我会写这篇文章呢？ 源于今天讨论，提到这个组件化开发和以前没有多大区别，都需要合作编码，共同开发某些相同模块，本来之前都是按照模块划分来开发的，既然组件化开发还是这样，无非就是将代码分开编写然后再相互调用，我们还需要去搞什么自动化打包编译，分包等事情，那么我们有什么必要来组件化开发呢？

   每个人有不同的观点和体会，这个是很平常的，写这篇文章不在于想改变谁的想法，也不在于判定谁的对错，只是希望能够通过写出这篇文章来加深一下自己对于组件化开发的理解，同时也希望能够让别人看到并发现自己在这方面的理解不足之处。希望看到这篇文章的朋友能够回复更多自己的体会理解。下面就来说一说我在验证了一段时间的组件化开发的一些小体会：

   先上一张我们iOS组件化开发架构图：

组件化开发之于开发测试

• 更加利于开发出MVP（最小可运行版本）
• 项目或者业务越来越复杂的情况下，组件化开发更适合快速迭代，在添加修改组件时候不需担心影响其他组件
• 解决业务模块划分不清晰，耦合度大，较难维护
• 可单独开发，测试，发布一个组件，不需要像以前一样开发完某个功能，就需要编译、运行、打包整个项目
• 某个组件出现问题，可直接对组件进行处理，不必担心会因为修改而影响到整个工程
• 业务组件之间调用标准化（通过统一的Mediator进行通信，而非直接引用，降低代码耦合度）
• 组件只需要提供一种服务能力或者接口，由中间件调用或发现服务，服务对组件间无侵入性
• 组件划分后，组件的开发不受其他业务影响，可以多个组件并行开发，加快开发进度
• 组件可以提供很好的提升代码的可重用性（而非可复制性），如果有其他项目需要该组件可以直接引入使用，而不是拷贝代码，拷贝资源等
• 组件单独测试方便，测试完成后进行集中测试，如果后期有修改组件，只要组件提供的能力或者接口不发生改变，就不需要再次进行集中测试，减少测试工作量
• 如果有新人的加入，可以直接分配组件进行开发，而非需要熟悉整个项目，可以从一个组件的开发使新进人员比较快速熟悉项目、了解到开发规范

组件化开发之于产品

   长期以来都是产品指导我们开发工作的进行，如果我们推行实现了组件化开发，这个能不能在给产品思考的时候带来点什么呢（以下只是个人臆测）？

• 是否可以指导产品需求分析，产品设计也能够融入到组件化开发中来，从产品最初思考角度实现组件化？
• 我们实现了组件化开发，每一个组件的功能描述清晰，是否能够为产品在与客户讲解或者在客户有新的需求（注意是需求而非需要）提供参考
• 往往产品需要比开发提前一个或者多个Sprint，可以从各个组件的实现情况了解到我们应该需要提前多久
• 组件是否能够更加的体现Agile的MVP（最小可运行版本）
• 通过组件开发完成的结构图，给运营、销售讲解更加方便简化，唔需要提供一个比较具体的PRD
• 有时候我们需要判定一个需求是否为真实需求，往往要通过数据反馈来体现，如果通过组件开发快速上线（开放组件内测版本），试错，是否能够更好更快的定量分析

组件化开发之于销售、技术支持

• 通过各个业务组件更加精细化的了解产品的功能，而非系统了解
• 在与客户沟通时可以更加专业的告知客户我们提供了哪些能力（我们没有的能力，特殊需求的客户可以自行开发接入）
• 在与客户沟通后，可以参与到每个组件的开发中来，提供建议，而非是对于整个项目提供建议 （这样往往是没有记录下来），对于一个组件提供建议可以比较快速的做出响应

组件化开发之于UI/UE设计

• 组件分离开来，对于指导UI设计、UE体验提供约束力，毕竟产品还需要有个开发的规范提供给第三方开发

组件化开发之于Future

• 组件中包含有基础组件，这些组件也算是技术的一种积累
• 为未来开发新项目提供更快速的响应

下面是我在组件开发中提供的其他技术文档，欢迎查阅：

组件化开发之-Cocoapods使用及创建发布自己的Pod
组件化开发之-pod创建规范
基于Jenkins搭建iOS持续集成开发环境
基于Jenkins使用Calabash配置iOS功能测试

由于刚刚开始组件化开发不久，很多好处和不太好的地方还未体会到，此篇文章会在后续持续更新。同时 ** 组件化开发** 系列文章我也会在后面持续输出。

转载于:https://my.oschina.net/u/216465/blog/904470