抽空重新看了一下今年的GMTC,读到链家郭晓铭的PPT:链家网移动端敏捷之术的时候忍不住写了这个笔记,大多数内容都是ppt上的原文。
大多数app存在的现象
- 业务简单
- 业务覆盖城市范围小
- 产品用户角色单一
- 业务单一、未形成线上线下的闭环
- 团队工作方式传统
- 团队规模小(人员密切配合，不存在业务线的分工)
- 瀑布式开发(版本需求比较稳定，在开发过程中很少调整)
- 手工打包上线(产品投放渠道少，发版节奏平缓，测试盒上线均靠手工打包)
- 架构简单 MVC架构
- 通用设计，学习和维护成本低。
- 对复杂业务不适应。业务逻辑变得复杂的时候，Controller将变得越来越大
第一阶段
- 地域业务差异
- 业务增多，内容型业务的形态多变
- 人员增多，人均产出下降，代码质量堪忧
基于短链的配置化
方法:
- Sever端下发城市配置(包含icon、标题、跳转短链、功能开关等)
- 跳转短链注册表(保存短链pattern与页面的类别、类参数名、短链参数名、默认参数值、跳转方式等的对应信息)
- 短链解析和页面跳转(使用注册表中的短链pattern做正则匹配，根据匹配到的消息创建页面并用对应的跳转方式打开)
优点:
- 更统一(各个业务的解析和跳转逻辑由跳转同意引擎同意处理)
- 更灵活(城市配置由路由端下发，城市业务范围的调整不依赖发版)
- 扩展性强(快速支持新增城市，且对新业务的支持不影响旧的功能)
业务快速上线和调整
使用Native + H5 的方式实现。
Native作为重点业务体验的保证。 H5负责内容型业务和运营活动
- 小巧清晰，不依赖第三方解决方案
- 消息传递安全，通过bridge注入参数信息，不是url
- 两端方案统一
项目质量缺乏保障
- 开发流程优化
- 代码规范形成(代码风格一致,提高可读性;统一的入口参数校验，异常处理等，提高健壮性)
- CodeReview(同步开发人员对代码和设计的理解；提前发现问题)
- 敏捷开发模式(随时交付，提早反馈)
第二阶段
- 多个业务团队并行开发
- 多个新产品需要快速上线(需要能够复制已有功能，快速上线)
- 对接后端团队越来越多(沟通成本高，发版风险大;不同团队接口数据格式差异大，客户端数据解析和校验逻辑复杂)
组件化
组建间的调用方案
组建: 各个组件之间相互独立，不直接调用，而是通过中介者Component Mediator相互调用
CM:按组建拆分，每部分为该组建支持的调用方式
组建接口: 各组件针对组件间调用做相应接口类。CM通过反射机制调用该接口类的相应方法。
组件化过程中的风险控制
- 代码仓库分离
- 主工程代码、公共模块代码、以及各业务组件代码仓库分离
- 权限控制
- 为单个业务团队配置公共模块代码，以及其他业务代码的只读权限
- 建立接口类的命名规范
- 对组件接口类名以及接口接口方法的命名统一规范，降低开发成本
- 接口类的CodeReview
- 接口类出错的影响范围相对较大，需要业务负责任对接口类做重点review
- 热修复
- 紧急修复组件化过程中造成的线上问题；每个补丁不允许超过1个版本
API团队引入
引入API团队可以减少客户端和多个Sever端交互。
- 沟通成本降低
- 发版风险降低
- 业务逻辑简化
移动端与后端配合开发流程
第三阶段
- 插件化(用户对产品功能做个性化定制，减少安装包体积，降低发版成本)
- 跨平台技术(最小的成本覆盖到两个平台，避免重复开发)
- 安全性(更多交易内容线上化)
