会议介绍
会议日程
（最终日程以会议现场为准）
|
|
|
|
- 程序代码越来越乱
- 软件维护成本越来越高
- 软件变更越来越困难
- 无法进行新技术的改造
- 头痛医头，脚痛医脚
- 抛弃掉重新编写
- 因担心未来变化而做的过度设计
- 团队成员越来越多但效率却越来越低
- 测试变得越来越困难而任务繁重
- 软件系统越来越笨重而不适应未来变化
- 起初的设计
- 随后的变更
- 质量不断下降的过程
- 软件总是因变更而变得越来越复杂
- 软件结构已经不再适应复杂的软件需求
- 必须要调整软件结构以适应新的软件需求
- 重构原有代码以适应新的需求
- 实现新的需求
|
|
- 演示以往软件设计的过程
- 剖析以往软件设计的问题与风险
- 用最快的速度开发一个最核心的功能
- 让第一个版本运行起来并可以验证
- 在第一个版本的基础上不断添加功能：
- 每次只添加一个很简单、很单一的功能
- 每次以两顶帽子的方式添加新功能
- 运行、调试与验证
- 重复这个过程添加下一个功能
- 复杂的系统就是由一次次正确开发的不断积累而成
- 复杂功能有效地解耦
- 代码编写总是可测试与验证
- 简化设计与思考的复杂度
- 适时重构以避免软件退化
|
|
|
- 重构是一系列代码的等量变换
- 重构的保险索：自动化测试
- 软件修改的四种动机——重构的价值
- 一个真实的谎言——重构的误区
- 重构的主要方法与技巧
- 重构第一步：分解大函数
- 重构第二步：拆分大对象
- 重构第三步：提高复用率
- 重构第四步：可扩展设计
- 重构第五步：降低耦合度
- 重构第六步：系统分层
- 重构第七步：领域驱动设计
|
|
- 重构是一种习惯
- 重构让程序可读
- 重构，才好复用
- 先重构，再扩展
- 紧急任务时的重构
- 重构初期的困局
- 解耦与自动化测试
- 建立自动化测试体系
- 评价软件质量的指标
- 评价软件质量的工具
|
|
|
- 适配器模式解决第三方框架带来的难题
- 适配器模式解决外部接口的设计难题
|
|
- 案例：工资发放功能设计改进的过程
- 工资发放功能的Java实现
- 工资发放功能的C++实现
- 案例：数据导出功能的设计实现
- 深入理解开放-封闭原则
- 数据导出功能的变更与改进过程
- 案例：财务凭证生成功能的设计过程
- 财务凭证生成功能的初始需求与设计
- 财务凭证生成功能的扩展与分析过程
- 财务凭证生成功能的最终设计
- 深入理解单一职责原则
- 学习“两顶帽子”的设计方式
|
|
- 依赖反转原则的设计难题
- 开放-封闭原则的设计难题
- 探讨工厂模式的本质
- 简单工厂模式的C++实现
- 基于配置的简单工厂模式
- 剖析简单工厂如何实现依赖反转原则
- 解读工厂模式对设计的重大意义
- 讲解如何创建一个工厂
- 创建工厂的步骤与关键点
- 利用Spring框架简化工厂类的设计
- 工厂方法模式的概念
- 工厂方法模式的应用
- 抽象工厂模式的概念
- 最初的标签库设计
- 运用简单工厂的标签库设计
- 运用工厂方法的标签库设计
- 运用抽象工厂的标签库设计
- 最终基于配置的标签库设计
|
|
- 单例模式带来的设计变革
- 充血模型vs.贫血模型
- 探讨单例模式与性能问题
- 单例模式改变了很多软件的设计
- 工厂类在提供产品时遇到的设计问题
- 原型模式及其概念
|
|
- 重复代码带来的严重后果
- 散弹式修改及其解决思路
- 探讨实现代码复用的难题
- 代码复用在不同场合采用的方法
- 模板方法模式在代码复用中的作用
|
|
- 多数据源问题的分析设计过程
- 多数据源的设计与实现
- 商城收银系统期初的设计
- 混合策略的设计与实现
- 多层装饰者的设计与实现
- 透明的功能扩展
- 里氏替换原则
- 员工管理与工资发放带来的继承泛滥问题
- 采用桥接模式的设计与实现
- 查询支持类遭遇的继承泛滥问题
- 查询支持类的解决方案
- 单例模式下查询支持类的设计
|
会议嘉宾
（最终出席嘉宾以会议现场为准）
参会指南
温馨提示酒店与住宿:为防止极端情况下活动延期或取消，建议“异地客户”与manbext客户端下载客服确认参会信息后，再安排出行与住宿。退款规则:活动各项资源需提前采购，购票后不支持退款，可以换人参加。
您可能还会关注
.png)
收藏人
会员折扣
该会议支持会员折扣 具体折扣标准请参见plus会员页面
