单体应用的平台化改造

当前的问题

1. 从UI到数据为一个整体，是典型的单体应用。只是靠文件夹进行模块分离，划分文件的标准也有多种，不利于业务的快速扩展。

2. 支持iOS7，导致bitCode，HealthKit，WebKit等重要特性无法支持。SDK也只能用静态库的方式（.a），不能用动态库的方式（.framework）

3. 缺少独立的“无线网关”，客户端开发依赖后台进度

4. 人员分散在直营，金融，共享平台，后端等各部门，难以形成合力

单体应用.jpg

解决方案

1. 将共用部分抽出来，为多业务扩展做准备，形成平台型应用

• 共用组件，比如网络通讯，数据缓存，加解密等
• 公共业务，比如登录注册，人脸识别

2. 最低支持iOS8，全面使用动态链接库（.framework）

• iOS10即将发布，是时候升级iOS7了
• 向上适配（iOS10），向下防止碎片化（iOS7）
• 代码组织和 FRAMEWORK

3. 提供独立的“无线网关”

• 与现有的PC端业务隔离
• 流量控制，实现“灰度发布”
• 减少对后台进度依赖；可以在“无线网关”设置demo数据，让客户端先于后台服务开发
• 将一些客户端功能归集到“无线网关”，实现“轻客户端”
• “流程聚合”将涉及多个后台服务的API进行聚合之后供客户端调用

4. 直营，金融，共享平台，无线网关等相关人员形成一个虚拟的“无线开发”团队，形成合力。

• 新拉分支开发，现有代码保持不动
• 今后一段时间（平台化改造期间）限制新业务，新业务在原代码中实现，按照改动最小原则执行
• “无线开发”人员坐在一起，形成“作战室”效应，齐心协力进行平台化改造
• “双版本”进行一段时间之后，用成熟的“平台化版本”替代现有的“单体应用版本”

组织架构图

无线团队.jpg

• 共享平台提供公共组件，与具体业务无关的通用逻辑
• 金融、直营等专注于业务相关的界面和业务逻辑

技术架构图

平台型APP.jpg

• “核心服务”按照“微服务”的思路开发，粒度可以细一点，职责单一一点，基础组件，专门供其他组件调用。比如网络，数据库，加解密等等与业务无关又高内聚的模块。
• “核心服务”之间最好不要相互调用，高内聚，清晰的隔离，关系简单
• “通用逻辑”应该是一些跟具体业务无关的公共业务，比如数据统计，消息推送，登录注册，人脸识别，支付，分享，常用的工具箱等等
• “通用逻辑”可以被别的模块调用，也可以相互之间调用，也可以有相应的界面和交互，也可以进行组合，提供“聚合服务”。主要目的是提高模块复用度，让不同APP，不同业务能够更专注于自身特有的业务和产品体验
• “业务逻辑”调用“核心服务”和“通用逻辑”提供的服务，开发业务相关的模块
• “业务逻辑”应该是跟“用户界面”无关的，不要有View和Controller相关的内容。主要目的是给Controller减负，方便让“用户界面”调用，同时降低由于“用户界面”频繁变更带来的影响。
• “业务逻辑”由各业务部门开发，内部模块之间可以相互调用，各部门提供的模块之间要做好相互隔离
• “用户界面”可以不考虑模块复用，重点考虑快速应对变化和提升用户体验
• “用户界面”最好只包含View，Controller，XML，ViewModel（仅仅是显示逻辑，不要包含业务逻辑），专注于界面显示和页面跳转，其他的通过调用“业务逻辑”、“通用逻辑”提供的服务来实现
• “用户界面”的开发最好和交互，视觉同学一起开发，协同合作提升用户体验，快速应对变化。这一层，要“尽量薄”
• “用户界面”的开发以APP为单位，相互业务部门的开发人员应该合成一个团队开发。代码的组织上也是“平铺式”的，界面之间相互隔离，互不影响；方便各自独立修改，快速应对变化
• “用户界面”的开发当然也提倡“规范组件”，以“组合”的思路将页面分块，进一步降低复杂度。

方案选择

方案1：演化思路（最保守）

• 在一个版本上开发，不拉新的分支
• 将需要平台化的内容隔离出来，做成调用库
• 将独立出来的代码移出现有工程，单独管理
• 随着业务的发展，时间的推进，一个模块一个模块演化

优势

• 只有一个版本，维护简单
• 及时测试，一直在使用，功能得到验证

劣势

• 业务功能实现和平台改造混合，带来任务优先级取舍等一系列问题
• 影响了业务实现的进度
• 受限于现有版本的限制，很难做大规模的重新设计

方案2：重构思路（平衡型）

• 重拉分支，跟现有版本完全隔离
• 仍然用Object-C，跟现有版本无缝对接
• 双版本发展，各自完成不同使命
• 重新进行架构设计，可以做较大规模的改动
• 平台部分改造完成，再对接新业务
• 用平台版本替代单体版本

优势

• 业务和平台分开，互不影响
• 业务开发和平台改造，可以交给不同的团队完成
• 可以进行大规模的重新设计

劣势

• 版本融合时，带来额外的测试与维护工作

方案3：用Swift重写（最激进）

• 重拉分支，跟现有版本完全隔离
• 着眼于2年之后的主流趋势，重新设计
• 双版本发展，各自完成不同使命
• 先完成核心模块开发
• 再完成公共逻辑开发
• 再接入业务逻辑和界面
• 在平台型应用成熟之后，完成单体应用到平台应用的切换

优势

• 符合苹果的指导方向，用Swift替代Object-C
• 2年后，如果Swift成为主流，不需要再进行版本重写工作
• 开发人员也能跟上主流的发展趋势，提升自身价值

劣势

• Swift熟练的开发人员不多，需要半个月到1个月的学习时间
• 版本管理，切换时带来额外的测试与维护工作

---

备注：关于Swift

• Swift是苹果主推的语言，是安全，高效，跨平台的一门现代编程语言
• Swift已经出来两年，增长迅速，目前（2016-5）已经和Object-C相差不远了
• 在一年前（2015-3），Object-C在TIOBE上的排名还是第3，Swift排第23，短短1年时间，变化非常大
• Swift3.0即将出来，语言将趋于稳定；预计再过2年，会显著超过Object-C
• 开发者本身大多支持Swift，也认可Swift取代Object-C的大趋势，但是现实工作中使用的机会却不多，比较尴尬。

TIOBE编程语言排行-2016-5.png

TIOBE编程语言排行-2015-3.png