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

原创 2016-05-19

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

   每一个人有不一样的观点和体会，这个是很日常的，写这篇文章不在于想改变谁的想法，也不在于断定谁的对错，只是但愿可以经过写出这篇文章来加深一下本身对于组件化开发的理解，同时也但愿可以让别人看到并发现本身在这方面的理解不足之处。但愿看到这篇文章的朋友可以回复更多本身的体会理解。下面就来讲一说我在验证了一段时间的组件化开发的一些小体会：

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

组件化开发之于开发测试

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

组件化开发之于产品

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

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

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

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

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

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

组件化开发之于Future

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

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

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

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