高效研发基础

设计方法与实践介绍

软件设计的目的：使软件在长期范围内能够容易的进行变化

软件设计的原则：

• 高内聚：紧密相关联的元素要放在一起
• 低耦合：单位之间要尽可能少的关联
• SOLID原则：简单正交设计
• 设计模式

clean code

• 排版整洁，逻辑清晰，扩展性好
• 命名规则：表达是什么，代码自注释，有意义的循环迭代变量
• 注释：版权信息、设计意图、警示信息
• 函数：单一职责，骨架函数、步骤函数
• 编码细节：使用自然的比较顺序、简化逻辑、缩小变量作用域

单元测试

• 单元测试 – 模块\组件级别测试 – 系统级别测试
• 降低产品开发的成本

单元测试的原则与模式

• tests as documentation，将单元测试视为文档工作
• fully automated and self-checking，自检性
• do no harm，不可破坏性
• keep tests as simple as possible，简洁性

重构

• 业务导向
• 小步快跑：主干、分支，问题拆分为小单元进行修改
• 演进式设计
• 正交设计原则：分离关注点、消除重复、缩小依赖范围、向着稳定的方向依赖

配置化架构

• 配置指的是对数据的抽象，需要架构上的描述
• 架构上描述的配置指的是对架构元素的抽象，描述配置化不完整
• 配置话包括对业务的抽象，尤其是逻辑
• 配置化包括对配置的管理及分支

配置化架构应用

• 业务配置化改造：组件配置化、构建DSL（Domain Specified Language）
• 提高配置的开发效率
• 降低配置的维护成本：在部署、数据版本、业务属性、架构描述这四个维度间参数能够共用；针对配置本身的语法，让配置支持合并；减少冗余信息；消除信息重复；使用配置的默认值

---

高效研发流程

• 从产品目标到产品路线：产品目标与收益、市场份额、流水有关，满足用户诉求是产品的基础职能
• 从产品路线到发布计划：用户故事地图（用户故事地图框架–时间线，一级粒度的功能需求Epic，二级粒度Feature，三级粒度Story），制定发布计划（Big Store进行细化讨论、按照价值和重要程度进行版本控制、确定每个版本的期望达成目标、确定每个版本的内容、团队达成共识）
• 从发布计划到迭代计划：选取迭代模式（集中发布式模式、迭代式发布模式），用户故事的拆分（影响迭代速率），用户故事的优先级排序，用户故事估算，迭代计划制定
• 从迭代计划到迭代的落地执行：迭代计划会、站会、需求评审会、迭代回顾会，分析、开发、测试

---

研发工具链

iCafe

• 需求管理：用户故事地图
• 迭代计划
• 进度跟踪：站会、卡片墙、燃尽图
• 持续改进：卡片状态时长散点图、卡片状态累积流图

iCode

• 工作流：基于分支的工作流（分支并行，独立开发，测试用例编写成本高）
• 评审：代码扫描、持续集成、人工评审

iPipe

• 固化端到端的交付流程
• 插件化现有的工具和服务
• 数据度量驱动过程改进

---

持续交付方法与实践

为什么要做持续交付

业务 – 开发 – 测试 – 运维

传统交付的问题：

• 分支冗余导致合并困难
• 缺陷过多导致阻塞测试
• 开发环境、测试环境、部署环境不统一导致的未知错误
• 代码提交版本混乱无法回溯
• 等待上线周期过长
• 项目部署操作复杂经常失败
• 上线之后出现问题需要紧急回滚
• 架构设计不合理导致发生错误之后无法准确定位

持续交付优势

• 需求阶段，用户故事便于理解；开发测试阶段，持续集成；运维阶段，保持开发环境和运维环境的统一
• 有效缩短提交代码到正式部署上线的时间，降低部署风险
• 自动的、快速的提供反馈，及时发现和修复缺陷
• 软件在整个生命周期内都处于可部署的状态
• 简化部署步骤，使软件版本更加清晰
• 能够让交付过程成为一种可靠的、可预期的、可视化的过程

敏捷开发Agile：需求阶段、研发阶段

Devops：开发测试、运维部署阶段

• Devops效能：发布频率、部署时间、平均修复故障的时间点、部署变更的失败率

软件交付能力指标

• 仅涉及一行代码的改动需要花费多少时间才能部署上线——核心指标
• 开发团队是否在以一种可重复、可靠的方式执行软件交付

如何做到持续交付

持续交付

• 包括但不限于持续集成和持续部署

持续集成

• 代码的编译
• 近代检查
• 单元测试任务

持续部署

• 虚拟机技术
• 容器技术

可重复使用的持续交付流水线
代码合入 – 自动编译 – 初步的自动化单元测试 – 模块测试 – 系统测试 – 自动构建和部署 – 提测 – 系统测试 – 发布 – 预上线 – 正式上线

持续部署

容器技术

• 上手简单，轻量级架构，体积小
• 集合性好，更容易对环境和软件进行打包复制和发布

部署原则

• 部署包全部来自统一的存储库

• 所有的环境使用相同的部署方式

• 所有的环境使用相同的部署脚本

• 部署流程编排阶梯式晋级，即在部署过程中需要设置多个检查点，一旦发生问题可以有序的进行回滚操作

• 整体部署由运维人员执行

• 仅通过流水线改变生产环境，防止配置漂移

• 不可变服务器

• 部署方式采用蓝绿部署（部署的时候准备老旧两个版本）或者金丝雀部署（新版本发布时，少量用户先使用新版本）

• 服务描述

• 流程控制

• 数据度量和分析