课程简介
一个背景:软件产品化
一个中心:可扩展设计
一套实践:拉通需求、设计和代码,让“需求的变更”变成“代码的扩充”
目标收益
一个背景:软件产品化
一个中心:可扩展设计
一套实践:拉通需求、设计和代码,让“需求的变更”变成“代码的扩充”
培训对象
1.想听架构课程的所有学员,包括架构师、技术经理、开发高手、开发骨干
2.想从重复做项目,过渡到做产品的团队
课程大纲
Big Picture——产品化:误区与真相 |
产品化,就是死磕“可扩展” 可扩展的实质:需求有变更,代码可方便扩充 远离代码不行:代码可扩充?架构设计是条件,详细设计是关键 成功的两个条件和两个关键 【条件一】将产品扩展压力,捕捉为需求 【条件二】架构要稳定,即代码扩充时架构不变 【关键一】模块间接口是隔离模块、使模块可扩展的关键 【关键二】模块实现是否重用与可变分离,是第二个关键 |
【需求篇】 产品扩展压力,如何尽早捕捉为需求? |
设计产品化软件,洞察需求变更的几点规律 1. 什么需求没变? 2. 什么需求在变? 3. 分析和识别需求变更的实际技巧 设计产品化软件,可这么加强需求文档 1. 分析: 《SRS》案例一 vs. 《SRS》案例二 2. 练习:学员将需求的变更,定义到这两份文档中 主要收获:体会《SRS》的变更包容力不同 主要收获:长期以来“输入-处理-输出”式需求的弊病 主要收获:专业的话,用例技术这么用 分析、识别需求变更实战 1. 小组任务:应用上述技巧,分析和识别功能变更 2. 小组提交:xxx组《用例图 + 用例规约》 3. 小组对标:老师提供的《用例图 + 用例规约》 |
【架构篇】 为支持扩展,产品化的架构必须稳定! |
设计师划分模块时,代码结构的全局划分方法 1. 从模式开始——巧妙的“五横一纵”分层模式 2. 模块划分——覆盖上下文图定义的接口需求 3. 模块划分——覆盖功能树、用例定义的功能需求 3.1. 起步:分析用例规约,识别实现用例需要哪些类 3.2. 后续:协作设计,即用序列图、协作图串起这些类 3.3. ……即运用用例驱动设计思维 专项练习 1. 用例驱动 2. 到底是“用例模块类”还是“用例类模块” 设计师划分模块时,注意几个基本原则 1. 通用-专用分离:提炼应用无关的Library、或选择三方库 2. 通用-专用分离:机制与策略分离,开发或选择Framework 3. 隔离外部交互:仅UI层“知道”操作细节和展现格式 4. 隔离外部交互:仅SI层“知道”和外部系统通信的细节 5. 隔离外部交互:仅DM层“知道”数据存储格式 设计师划分模块时,可参考的优秀范例一则 1. 著名开源产品套件——Mumble 主要收获:模块的划分、通用库的提炼、三方框架… 实战演练 1. 任务:模块划分,必须覆盖代码结构全局、不能漏模块 2. 贯穿案例推进…… |
【详细设计上】 承载产品功能的代码模块,重用与可变分离! |
设计师设计模块时,利用好OO Package结构规律 1. 提供中心控制类,不要暴漏一堆小类 2. 接口类与实现类分离 3. 通用实现类与扩展实现类分离 4. …… 如何应用上述结构,包容需求变更 1. 分析需求变更,扩充/增加/改变 用例规约 2. 分析对设计的影响 a) 增加了Optional Feature (最常见) b) 改变了Function Point c) 改变了Process Flow 3. 如何设计合理的OO Package支持上门三种变更 设计师设计模块时,可参考的优秀范例二则 1. 一个通用库——类的组织 主要收获:接口分离、提供中心控制类、可扩展支持 2. 著名开源产品——类的组织 主要收获:抽象领域概念的提炼、可扩展支持 过关演练 1. 分析材料,熟悉设计要求 2. 设计一个通用模块,必须可扩展…… |
【详细设计下】 设计松耦合、可扩展的模块接口 |
设计师设计接口时,考虑的三件事儿 1. 技术选择:接口设计容易?做漂亮最难! 2. 机制选择:调用/回调/同步/异步/轮询/超时 3. 格式定义:函数风格 vs.报文或消息风格 设计师设计接口时,可参考的优秀范例几则 1. 某通用产品——漂亮的封装、方便的配置 主要收获:围绕Domain Type定义模块的核心接口 主要收获:在核心接口基础上,可定义便捷接口 注英文术语为Core Interface、Convenience Interface 2. 某平台接口分析——既能跨平台又方便调用? 主要收获:跨平台协议 + 便于二次开发的API 1. MFC、Swing等API设计对比——更灵活的接口风格 主要收获:Message在接口设计中的作用 主要收获:Callback回调、及“注册-回调”接口机制 设计师设计接口时,这些经验可以用 1. 基于代码:专项练习一 2. 基于代码:专项练习二 3. 基于代码:专项练习三 4. 原则与“坑”总结 实战演练 1. 任务1:接口的命令化(Command)支持可扩展 2. 任务2:让接口包含回调(Callback)使模块通用化 3. 贯穿案例设计推进…… |
Big Picture——产品化:误区与真相 产品化,就是死磕“可扩展” 可扩展的实质:需求有变更,代码可方便扩充 远离代码不行:代码可扩充?架构设计是条件,详细设计是关键 成功的两个条件和两个关键 【条件一】将产品扩展压力,捕捉为需求 【条件二】架构要稳定,即代码扩充时架构不变 【关键一】模块间接口是隔离模块、使模块可扩展的关键 【关键二】模块实现是否重用与可变分离,是第二个关键 |
【需求篇】 产品扩展压力,如何尽早捕捉为需求? 设计产品化软件,洞察需求变更的几点规律 1. 什么需求没变? 2. 什么需求在变? 3. 分析和识别需求变更的实际技巧 设计产品化软件,可这么加强需求文档 1. 分析: 《SRS》案例一 vs. 《SRS》案例二 2. 练习:学员将需求的变更,定义到这两份文档中 主要收获:体会《SRS》的变更包容力不同 主要收获:长期以来“输入-处理-输出”式需求的弊病 主要收获:专业的话,用例技术这么用 分析、识别需求变更实战 1. 小组任务:应用上述技巧,分析和识别功能变更 2. 小组提交:xxx组《用例图 + 用例规约》 3. 小组对标:老师提供的《用例图 + 用例规约》 |
【架构篇】 为支持扩展,产品化的架构必须稳定! 设计师划分模块时,代码结构的全局划分方法 1. 从模式开始——巧妙的“五横一纵”分层模式 2. 模块划分——覆盖上下文图定义的接口需求 3. 模块划分——覆盖功能树、用例定义的功能需求 3.1. 起步:分析用例规约,识别实现用例需要哪些类 3.2. 后续:协作设计,即用序列图、协作图串起这些类 3.3. ……即运用用例驱动设计思维 专项练习 1. 用例驱动 2. 到底是“用例模块类”还是“用例类模块” 设计师划分模块时,注意几个基本原则 1. 通用-专用分离:提炼应用无关的Library、或选择三方库 2. 通用-专用分离:机制与策略分离,开发或选择Framework 3. 隔离外部交互:仅UI层“知道”操作细节和展现格式 4. 隔离外部交互:仅SI层“知道”和外部系统通信的细节 5. 隔离外部交互:仅DM层“知道”数据存储格式 设计师划分模块时,可参考的优秀范例一则 1. 著名开源产品套件——Mumble 主要收获:模块的划分、通用库的提炼、三方框架… 实战演练 1. 任务:模块划分,必须覆盖代码结构全局、不能漏模块 2. 贯穿案例推进…… |
【详细设计上】 承载产品功能的代码模块,重用与可变分离! 设计师设计模块时,利用好OO Package结构规律 1. 提供中心控制类,不要暴漏一堆小类 2. 接口类与实现类分离 3. 通用实现类与扩展实现类分离 4. …… 如何应用上述结构,包容需求变更 1. 分析需求变更,扩充/增加/改变 用例规约 2. 分析对设计的影响 a) 增加了Optional Feature (最常见) b) 改变了Function Point c) 改变了Process Flow 3. 如何设计合理的OO Package支持上门三种变更 设计师设计模块时,可参考的优秀范例二则 1. 一个通用库——类的组织 主要收获:接口分离、提供中心控制类、可扩展支持 2. 著名开源产品——类的组织 主要收获:抽象领域概念的提炼、可扩展支持 过关演练 1. 分析材料,熟悉设计要求 2. 设计一个通用模块,必须可扩展…… |
【详细设计下】 设计松耦合、可扩展的模块接口 设计师设计接口时,考虑的三件事儿 1. 技术选择:接口设计容易?做漂亮最难! 2. 机制选择:调用/回调/同步/异步/轮询/超时 3. 格式定义:函数风格 vs.报文或消息风格 设计师设计接口时,可参考的优秀范例几则 1. 某通用产品——漂亮的封装、方便的配置 主要收获:围绕Domain Type定义模块的核心接口 主要收获:在核心接口基础上,可定义便捷接口 注英文术语为Core Interface、Convenience Interface 2. 某平台接口分析——既能跨平台又方便调用? 主要收获:跨平台协议 + 便于二次开发的API 1. MFC、Swing等API设计对比——更灵活的接口风格 主要收获:Message在接口设计中的作用 主要收获:Callback回调、及“注册-回调”接口机制 设计师设计接口时,这些经验可以用 1. 基于代码:专项练习一 2. 基于代码:专项练习二 3. 基于代码:专项练习三 4. 原则与“坑”总结 实战演练 1. 任务1:接口的命令化(Command)支持可扩展 2. 任务2:让接口包含回调(Callback)使模块通用化 3. 贯穿案例设计推进…… |