ppt.md

PPT

个人简介

  • 职业规划向技术专家方向发展, 往技术方向
  • 对技术充满热情, 喜欢钻研新技术, 提高工作效率

分层搭建

微服务架构

  • 分而治之面对复杂问题对惯用方法
    • 微服务在拆分和治理两个方面给出了很好对实践经验( 亚马逊两个批萨团队 )
  • 业务对复杂性需要新新的架构
    • b/s -> mvc 架构 -> 四层架构
    • android 的在升级新的编译架构, 分布式编译
  • 异构的技术架构
    • 架构通过 API 和消息的方式来协作
      • 结合我们自己业务的特点, 流程和业务比较多, 而并发和吞度量
      • 不与特点的语言绑定, 提供 Java 的最佳实践
    • 可以快速方便的集成其他和适配其他的业务

领域建模

  • 微服务如何拆分和设计
    • 领域用来确定业务的边界, 并在边界内解决业务问题
    • 业务也需要按照 "高内聚低耦合" 的方法进行拆分
  • 业务不断迭代, 需要持续维持业务和代码的一致性
  • 怎么做
    • 技术架构设计评审
    • 需求非常复杂, 变化也非常快, 不可能研发个半年
      • 在项目中使用到的时候逐步进行落地
  • 核心域, 通用域和支撑域, 有些可以通过采购或外包来完成

业务组件

  • 没有银弹
  • 按照领域拆解之后, 领域之间存在不同程度的可复用性
  • 为了不重复造轮子, 尽可能的服用业务能力
  • 从技术角度来讲, 今年我们做一件事情需要 1 个月, 明年做类似的事情可能只需要 1 个星期

基础设施

  • 公司自己的特点, 安全性的考量
  • 互联网的业务让基础设施的技术发展的非常快, 包括云技术/ 大数据
  • 微服务架构对基础设施的要求比较高, 对基础设施对稳定性, 按需交付能力
  • 微服务架构的缺点
    • 对基础设施要求比较高
    • 这一块 Java 生态提高了丰富的
  • 引入微服务给测试联调新增了复杂性, 导致不必要的成本消耗

关键交付物

  • 提案这一机制是开源社区的运作机制

分支管理域

  • 叠加
    • 打造传英自己工程实践的概念
    • 这些概念是在下游工具链上叠加起来的
      • repo 工具链是 android 代码的管理本身是在 git 单个仓库基础上叠加起来的一样
    • 通过 gerrit 来实现的我们自己的分支权限管控和代码 review
  • 业务规则
    • 分支命名规则
    • 代码合入上下游卡控规则
      • 临时量产分支需要合入代码必须先合入量产

研发基础设施层

  • 敏捷的运转依赖低层的基础设施的能力
  • 互联网包括构建了蓝绿维度发布, A/B 测试等能力
  • 基于数据流量的调度策略, 这些暂时不是我们工作的重点

Web 制品环境晋级

  • 统一交付的制品, 屏蔽了环境的差异
  • 类似于整机的版本外发流程

Web 开发分支规范

  • 单仓的规范

场测

  • 业务价值
    • 大禹子项目-场测管理系统与 IPM 测试平台联动
    • 实现测试域的海外测试闭环协同：实现任务确认->范围确认->任务发布->任务各国排期->时间确认->各国报告回收->场测报告回收，覆盖海外测试全过程
  • 收益
    • 海外活跃用户约 300, 数据统计
    • 除手工用例执行过程之外，测试过程整体提效 110%，250mins -> 120mins（ 120mins）

IPM 共创项目域

项目域的版本迭代

  • 共性问题通过 Excel 导入, 未来流程和数据上可以联通 JIRA 中的共性问题缺陷

大禹项目目标

  • 流程承接
    • 吻合 IPD 流程, 软件开发流程同 IPD 对齐
    • 与 KT5/KT4 子专项协同, 对软件项目管理, 需求跟踪, 软件版本发布等流程进行全景梳理和优化, 保证软件工程化的推进和实现
  • 高效协作
    • 串联业务断点，整合割裂平台，实现一站式软件开发高效协作
  • 效能洞察
    • 沉淀端到端数据，洞察分析效能问题，持续优化改进

度量指标

  • 可持续性
    • 业务活动的覆盖率
    • 业务流程 e 化率
    • 组件服用率
    • 临时方案, 未站在全局思考问题
  • 有效性
    • 每版本编译的被使用率被使用的比例
    • 目标用户使用率
    • 用户体验满意度
    • 项目交付时间缩短
  • 效率
    • 开发效率
      • 自动化冒烟测试覆盖率
    • 版本发布平均耗时提升率
    • 代码规范等引起的问题占比减少

问题

  • 交付物通过线下表格进行流转, 信息传递慢, 变更难管控
  • SPD 重要信息通过 excel 来进行传递, 数据跟踪困难
  • 审批通过邮件方式流转, 效率低
  • 流程未完全串联起来, 版本编译需要填写信息
  • 没有统一的需求管理, 需求管理比较零散
    • 需求关联到代码, 代码关联到版本, 反项搜索
      • 版本验证需要补充信息方向追踪到问题的源头
  • 开发立项后
    • 软件申请相关的开发资源靠邮件申请, 时效性和审批存在漏洞
  • 编译
    • android 的分布式编译优化
    • android 编译的工作负载, 调度, 采用云原生的技术, 弹性伸缩