序言
过去十几年，国内移动互联网浪潮崛起，移动应用的构建也如雨后春笋，从一开始大约是在2011年业余开发者做一款播放器放到App Store可以产生最多百万月流水[1]， 到现在，满目琳琅到App，珍惜手机空间如金，不肯多装一款普通的App的时代，经历过一波又一波的技术革新，自从CocoaPods于2011年9月1日时编译了第一个公开版本[2]，开启了iOS项目拥有应用级别的依赖管理器到时代。
在移动互联网领域从蓝海变成红海的过程中，项目构建的初期也慢慢从不拘小节的架构转向组件化架构的演进。
1. 不拘小节的架构设计
可以理解为一种为了
- 一些厂商快速试错，快速投入市场验证业务模式的可行性
- 一些厂商为了低成本快速交付一些外包项目
上述实践有一个共同点，就是没有考虑到后续的持续维护的成本与代价。
不拘小节的架构通常以如下方式存在：
1.1、初期的iOS项目以Project工程为主，各种从网上摘取
- 代码块
- 各种功能类
- 某些开源或者不开源的能力库（以lib或者framework方式集成）
拼接而成，
1.2、在引入CocoaPods之后
- 代码块
- 各种功能类
- 某些开源或者不开源的能力库（以lib或者framework方式集成）
- 以CocoaPods的方式集成公有私有的代码库（轮子）
不拘小节的架构一般用于中小型，短时间内交付的产品，上述方式可以做到快速实现以及交付的可视化效果，而可持续性维护则无人关心。
随着一些厂商快速占领市场，以及试错验证可行之后，由于项目到架构随意，参与人员不稳定等因素，加上破窗效应，以及不断形成风气的降本增效的企业诉求，这些团队将会面临维护成本不断攀升的高昂代价。
2. 组件化架构设计
2.1 不拘小节的架构设计的现状
不拘小节的架构团队会面临什么现状？大致可概括为：
- 历史问题挤压多：代码冗余，诸多历史问题未能及时发现
- 定位修复问题难：代码混乱，问题定位代码分散，定位成本大，修复不彻底
- 需求开发周期长：没有清晰规划，导致需求开发重复造轮子，增加了研发成本
2.2 组件化架构设计解决的问题
不拘小节的架构设计随着时间推移会遇到哪些问题呢？大致可概括为：
- 混乱：代码统一写在一个工程内部，查找定位问题困难
- 冗余：相同功能的代码实现多套，修复问题不彻底
- 不可复用：无可复用的模块，多App之间需要重复实现
2.3 组件化架构设计带来的问题
而组件化架构则可以弥补不拘小节的架构方式的诸多短板，降低项目的持续维护成本与代价，又能做到哪些改进呢？大概可概括为：
- 高效解决问题：代码划分模块，修复问题及迭代维护形成闭环，提升效率
- 清晰代码架构：清晰的调用链，解决问题漏改，改不全等逃逸到线上的问题
- 可复用的能力：跨App共建能力，减少维护成本
3. 组件化周期
根据笔者在不同团队（初创团队～BAT一线团队）的观察，常规耗时根据项目大小和团队成员规模以及过程中的需求数量等情况大致为10～100人月/单端不等。笔者前公司是一线大厂，团队规模大，项目大，总共投入5～10人，前后1年6个月完成对现有项目的初步组件化改造，而对于创立之初的创业团队，这个代价往往只需要10%。考虑到成本问题，组件化宜早不宜迟。
4. 组件化架构设计的思路
- 功能组件的清晰的定义与划分
- 层次分明的基础模块设计，
- 上层的业务模块解偶
