设计方法与实践介绍
软件设计的目的：使软件在长期范围内能够容易的进行变化
软件设计的原则：
- 高内聚：紧密相关联的元素要放在一起
- 低耦合：单位之间要尽可能少的关联
- 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效能：发布频率、部署时间、平均修复故障的时间点、部署变更的失败率
软件交付能力指标
- 仅涉及一行代码的改动需要花费多少时间才能部署上线——核心指标
- 开发团队是否在以一种可重复、可靠的方式执行软件交付
如何做到持续交付
持续交付
持续集成
持续部署
可重复使用的持续交付流水线
代码合入 – 自动编译 – 初步的自动化单元测试 – 模块测试 – 系统测试 – 自动构建和部署 – 提测 – 系统测试 – 发布 – 预上线 – 正式上线
持续部署
容器技术
- 上手简单，轻量级架构，体积小
- 集合性好，更容易对环境和软件进行打包复制和发布
部署原则
|