推荐讲师
国内顶尖的数据库调优实战专家,现任Oracle公司研发中……
曾任职BEA(中国)资深软件架构师,十余年的企业软件架……
10余年国际、国内知名高科技企业研发实践和研发管理……

软件重构实战训练营

培训时间:不限
培训地点:北京
培训费用:
培训简介:
【课程背景】
软件重构面临的背景都是相似的,程序员们为了快速完成需求和上线而写出了最基本的代码。然后在功能的不断扩充过程中,以打补丁的方式对代码进行扩充,中间还会面临着开发人员的变更和离职。逐渐地,代码就会变得越来越臃肿,渐渐地变得难以维护。 很多开发人员对重构有着严重的误解,错误的认为重构是专门安排一个阶段来进行的。但是,我们认为重构是持续进行的,而不是在项目结束时、发布版本时、迭代结束时,甚至不是每天快下班时才进行的。重构是我们每隔一个小时或者半个小时就要去做的事情。通过重构,我们可以持续地保持代码尽可能干净、简单并且具有表达力。因此,重构成为了每个开发人员必备的基本技能,可是国内的开发人员却很少去做。 那么,糟糕的软件代码会有什么样的影响呢?首先是开发效率的降低,在糟糕架构下加入新功能,会受之前代码的影响,可能存在意想不到的改动点和问题点,开发和调试时间都会大大增加;其次是故障率的提升,在质量低下的代码中,总是容易隐藏着很多不易发现的坑,这些都会成为故障的隐患;同时,架构也会使得需求的完成大打折扣,使得设计好的目标,因为架构限制或者性能等原因,只能完成80%甚至更低。
【课程解决的问题】
大多数软件开发方面的培训都是关于新系统的设计和开发,讲师教你如何从无到有创建出一个新的应用来。然而,在真实的项目中,许多产品如今往往依然运行在基于复杂架构设计和传统技术实现的遗留系统上,并依赖着它们。如何摸索出有效方法应对这些遗留系统,已经成为我们最需解决的问题之一。 随着不同产品的推出,不同客户、不同版本的发布,需要维护的遗留代码越来越多,重构也就在所难免。不仅如此,所有的软件系统,经过一段时间的维护,都会逐渐变成遗留系统,并且都遭遇了缓慢而不可抗拒的腐化。因此,软件开发人员不得不面对既有系统的混乱代码。而本课程正是告诉你如何重构既有的遗留系统,如何重构代码、重构设计、重构架构。 本课程教你如何扭转系统腐化,重构复杂遗留系统,减低维护成本。在面对一个错综复杂的、不透明的、令人费解的系统时如何慢慢地、逐步地将其变成一个简单的、有良好组织和设计的系统。
【课程对象】
各类软件研发中心的软件设计师、架构师、项目经理、技术总监、质量部门经理。对于重构技术怀有疑问和困惑,需要梳理解答的团队和个人,效果最佳。
  代码重构 设计重构 软件腐烂监控 重构管理
程序员 必须精通 需要了解 需要了解 需要了解
设计师 必须精通 必须精通 需要了解 需要了解
架构师 必须精通 必须精通 必须精通 必须精通
数据库工程师 需要了解 需要了解 / /
质量管理 / / 必须精通 必须精通
管理者 / / 需要监控 需要了解
【课程特色】
本课程注重实战,采用案例贯穿方式完成实践,收集了大量的真实案例,针对项目过程中技术人员常犯的错误进行了汇总、研讨,并最终形成培训教程。本次培训从程序员的编程思维开始讲解,通过大量的真实案例,详细地介绍了重构需要注意的要点以及难点,这些知识都是讲师十几年经验的总结。 本次课程1/3时间讲解核心思想,1/3时间动手重构实践,1/3点评分析总结。
【学员基础】
l. 目前正在面临复杂遗留系统,必须需要维护和重构; 2.具有面向对象基本概念,熟悉基本设计模式.
【主讲老师】
范老师,业界称为“互联网老范”: 工作经历: 范老师先后在阿里、中国航天科工集团工作近15年。曾任阿里研发中心高级软件架构师,软件架构质量专家。现任中国航天某部门(涉密)高级系统架构师,技术专家委员会软件架构设计首席专家。 最难能可贵的是范老师仍然坚守在软件开发架构设计的一线工作。现在正在负责某大数据征信系统的技术总负责人。 技术特长: 范老师掌握丰富的软件架构设计经验,熟练掌握软件需求分析的方法、软件架构设计的过程和方法,从而积累了大量实际项目架构设计的经验。同时长期关注软件代码质量、遗留系统改造、重构等问题。先后主持或参与了数十个国内外大型软件项目,涉及领域包括互联网、航天、金融、财务、税务等领域。在实际工作过程中分别担任过需求分析师、主任设计师、项目经理、高级系统架构师、技术专家等各项职务。 社会贡献: 范老师是2014年、2015年TID质量竞争力大会架构专家演讲嘉宾。2015年中国技术大会首席架构专家演讲嘉宾。并且在各种刊物发表了“如何做好软件需求分析”等文章。同时又是畅销书《大话重构》的作者。
【课程内容】
    主 题 授课内容
第一部分 为什么软件需要及时重构
第一单元 
剖析软件质量不断下降的根源
质量不断下降的表现:
1. 程序代码越来越乱
2. 软件维护成本越来越高
3. 软件变更越来越困难
4. 无法进行新技术的改造
以往采取的措施:
1. 头痛医头,脚痛医脚
2. 抛弃掉重新编写
3. 因担心未来变化而做的过度设计
带来的问题
1. 团队成员越来越多但效率却越来越低
2. 测试变得越来越困难而任务繁重
3. 软件系统越来越笨重而不适应未来变化
分析与反思
 
案例分析:一个遗留系统的演化过程
1. 起初的设计
2. 随后的变更
3. 质量不断下降的过程
软件质量下降的根源:
1. 软件总是因变更而变得越来越复杂
2. 软件结构已经不再适应复杂的软件需求
3. 必须要调整软件结构以适应新的软件需求
 
软件是因需求变更而质量下降吗?
案例分析:推演软件变更的设计过程
应对软件变更的最佳方式:两顶帽子
1. 重构原有代码以适应新的需求
2. 实现新的需求
案例:演示两顶帽子的设计过程
第二单元 
高质量的软件设计过程
以往软件设计的过程:
1. 演示以往软件设计的过程
2. 剖析以往软件设计的问题与风险
小步快跑模式的开发过程:
1. 用最快的速度开发一个最核心的功能
2. 让第一个版本运行起来并可以验证
3. 在第一个版本的基础上不断添加功能:
a. 每次只添加一个很简单、很单一的功能
b. 每次以两顶帽子的方式添加新功能
c. 运行、调试与验证
d. 重复这个过程添加下一个功能
4. 复杂的系统就是由一次次正确开发的不断积累而成
案例:演示小步快跑的开发过程
小步快跑解决的问题:
1. 复杂功能有效地解耦
2. 代码编写总是可测试与验证
3. 简化设计与思考的复杂度
4. 适时重构以避免软件退化
 
测试驱动设计
1. TDD vs. 后测试开发
2. 案例:演示测试驱动设计的过程
3. 测试驱动设计的优势
4. 实践测试驱动设计的难题
讨论:自动化测试脚本应当由谁来写?
 
练习:运用小步快跑的方式设计一个软件
第二部分 重构实战
第三单元 
何为重构
软件重构的概念
1. 重构是一系列代码的等量变换
案例:一个Hello World重构过程
2. 重构的保险索:自动化测试
案例:Hello World的自动化测试过程
3. 软件修改的四种动机——重构的价值
4. 一个真实的谎言——重构的误区
5. 重构的主要方法与技巧
 
案例分析:重构一个大型遗留系统
1. 重构第一步:分解大函数
超级大函数及其危害
案例:演示大函数产生的过程
案例:演示抽取方法操作步骤
实践抽取方法会遇到的问题和解决方案
2. 重构第二步:拆分大对象
超级大对象及其危害
案例:演示超级大对象的产生过程
案例:演示抽取类的操作步骤
讲解单一职责设计原则
案例:演示“分久必合,合久必分”的重构过程
3. 重构第三步:提高复用率
讲解顺序编程及其危害
“不要重复代码”原则
案例:提高代码复用的6个方法
案例:演示新增代码时的代码复用过程
用静态检查工具检查重复代码
4. 重构第四步:可扩展设计
过度设计 vs. 恰如其分的设计
讲解“开放-封闭”的设计原则
案例:讲解可扩展设计的4个方法
案例:讲解新增代码的可扩展设计过程
5. 重构第五步:降低耦合度
案例:讲解接口、实现与工厂模式
案例:讲解外部接口解耦与适配器模式
案例:讲解继承泛滥问题与桥接模式
案例:讲解方法解耦与策略模式
案例:讲解过程解耦与命令模式
案例:讲解透明扩展与组合模式、装饰者模式
6. 重构第六步:系统分层
反思软件架构需要怎样的分层结构
遗留系统如何拥抱需求变化
遗留系统如何应对技术变革
7. 重构第七步:领域驱动设计
领域驱动设计的概念
讲解领域模型分析方法
讲解原文分析法与领域驱动设计
 
讨论:如何制定重构项目计划
练习:重构一个小程序并编写测试脚本
第四单元 
关于重构的讨论
什么时候重构
1. 重构是一种习惯
2. 重构让程序可读
3. 重构,才好复用
4. 先重构,再扩展
5. 紧急任务时的重构
 
测试的困境
1. 重构初期的困局
2. 解耦与自动化测试
3. 建立自动化测试体系
 
重构的评价
1. 评价软件质量的指标
2. 评价软件质量的工具
第三部分 系统级的重构项目实战
第五单元 
遗留系统的技术改造难题
技术改造的难题
一些大型遗留系统已经运行维护十年以上,现在面临着技术改造的难题:
1. 程序越来越乱:代码在退化,软件质量持续下降,维护成本越来越高;
2. 面临技术改造:一直在犹豫改还是不改,但现在到了不得不改的时候了。
 
以往的解决方案:
1. 修修补补,遇到什么问题就解决什么问题:
存在的问题:
a.始终治标不治本,不能从根本上解决许多问题;
b.有过一些改造,但不敢尝试真正的技术改造,越老的系统技术越落后
存在的问题:面临着被市场淘汰的绝大风险
 
2. 彻底丢弃原有系统重新开发,从而快速摆脱以往的技术债务
存在的问题:
原系统运行维护十年以上,积累大量繁复而细微的业务需求与程序逻辑,但在重做过程中都遭到遗失,给项目带来巨大的风险
 
问题的实质:
1. 面临巨大市场的压力,改造是想做不想做都得做的事情了;
2. 原系统中积累大量繁复而细微的业务需求与程序逻辑,既不在设计文档中,也不为现有的维护人员所掌握,但一旦遗失却严重后果;
3. 一边在技术改造,一边还有新的需求需要维护,意味着改造中的新系统,在还未替代老系统前,还要不断与老系统同步
正是有了如此多的难题与风险,使得旧系统改造面临进退两难的困境。
 
演化式重构解决方案:
1. 演化式地对原系统进行重构,渐进式地进行优化改进
不是丢弃原系统,而是从原系统开始,运用重构方法进行一小步一小步的优化与调整,使技术改造过程变得平滑
2. 培训、指导与审查并举,切实提高代码编写质量
首先对人员进行代码质量与重构的培训,制订代码规范与静态代码检查。在开发初期加强对每项设计的指导,之后组长责任制进行代码审查。
3. 组件开发-测试为一体的团队
一边改造,一边编写自动化测试脚本,让改造过程随时处于质量监控之下
4. 优化与维护并行开展,让改造工作快速起效
制订迭代式计划,每完成一次改造就发布一个可运行版本。之后的运行维护在该版本的基础上开展
5. 平台建设与系统重构并行开展,加快改造速度
分成平台组与重构组并行开展工作,一边在搭建新的技术开发平台,一边运用重构在优化原有系统,最终实现原有系统向新开发平台的代码迁移
第六单元 
系统级软件重构过程
案例分析:演化式重构的改造过程:
1. 概念及解决的问题
演化式重构的概念
建立领域驱动设计的过程
2. 模块的选择与迭代项目计划
先选择易上手、快速起效的模块开始改造
再选择最核心、最关键的模块进行改造
制订迭代式技术改造项目计划
3. 组建一个开发-测试为一体的团队
测试人员与开发人员同时开始工作
改造初期的自动化测试过程
逐渐编写自动化测试程序的过程
4. 平台建设与系统重构并举
重构组:
一边在重构,一边在升级维护上线,既使改造工作快速起效,又使重构的成功以最快的速度得到验证,降低改造风险
平台组:
构建基于领域的轻量级系统架构,既为旧系统代码移植创造条件,又为技术的更迭降低成本
5. 平滑地代码移植
代码移植的条件:
1)旧系统完成了代码重构,实现业务代码与技术代码的有效解耦;
2)新平台构建了一个基于领域的系统架构。
代码移植过程:
1)将旧系统中的业务领域层有效提取出来;
2)将业务领域代码放入新平台中
3)完成其它的配置、接口、前端界面等工作
4)运行、调试、测试
改造的效果:
1. 实现领域驱动设计,拥抱未来需求的变化
2. 建立自动化测试体系保障软件质量
3. 更加灵活而快速地应对未来技术的更新
讨论:系统级重构的经验与分享






国软育诚(北京)信息科技有限公司
电  话:010-68104951      
联系人:安培雄
手  机:15010101549   
E-mail:gryc_apx@skl-zg.com
网  址:www.skl-zg.com
办公地址:北京市西城区西直门外大街143号凯旋大厦A座