软件高质量代码体系最佳实践

技术负责人/技术总监/项目经理/项目管理人员/架构师/测试部门/质量管理部门/资深开发人员/一般开发人员

课程根据著名编程大师的理论： 编程是一种态度，编程是一种技艺，编程是一种习惯。 面向以下不同的人群，有不同收获。
技术负责人/技术 总监
总监
 了解业内先进的代码审查的形式、技术、技巧和流 程的成功经验，优化现有开发中心代码审核方法；  掌握业内成熟的自动化审核审查工具及方法，提升 开发人员在代码结构分析、代码质量度量、代码覆 盖率分析等方面的能力，并有效运用到项目研发工 作中。
项目经理/项目管 理人员/架构师/
学习其他研发机构的代码管理思想  代码管理手段  代码管理相关流程和相关工具  代码监控
测试部门/质量管 理部门
 代码审查  代码检查列表  代码管理手段  代码管理制度的建立
资深开发人员
 掌握代码编码规范、代码评审要点等知识，引导开 发人员养成正确的代码编写习惯；  编程技艺和相关编程实践  重构手段
一般开发人员
 编程技艺和相关编程实践  重构手段  代码坏味道

第一篇： 编程是一种态度-------价值观 主题 培训内容 备注 第 1 单元 代码 就是债务 内容一：代码是债务 1. 代码的认识---代码就是债务 2. 代码是债务，越少越好 3. 你拥有的代码越多，添加新内容所要付出的成本就越 高 4. 通过案例分析让代码库尽可能小的方法： 5. 通过国际研发中心电信计费系统演示代码是债务的 思想，10 多年国外研发团队设计与研发第一版本，目 前几百人在维护 通过项目演示通过重构如何减少了一半的代码，维护的人 员的减少

项目的失败可能归咎于各种各样的原因。一些项目因糟糕 的需求而失败，另一些则由于钱和时间超支了，还有少数 单纯是因为糟糕的管理所致。如果我们探究其根本原因， 是否会发现所有项目失败的罪魁祸首是糟糕的代码呢？

Bob 大叔坚信糟糕的代码所带来的成本之大足够让一个 项目失败。

内容二 软件界要以新视角看待代码 1. 传统的软件工程对代码的错误认识 2. 代码的两面性，代码的静态结构和运行时行为 3. 客户和管理者往往仅仅关注代码的运行时的行为 4. 温伯格认为的主管必须关注代码 5. 软件设计与代码的关系—真正好的设计是在编码阶 段一步一步而形成的,通过案例分析，设计如何根据代 码进行演化 6. 编程真的是简单的劳动吗？ 7. 通过多家项目案例进行分析，传统思想对代码的种种 误解，我们提出了从 3 种新的角度来观察代码， a) 从管理者的角度，我们仅仅观察代码的运行时行 为，导致代码的静态结构混乱的根源。这就是代 码的冰山原理，大量垃圾代码隐藏在冰山之下。
b) 设计师的角度认为只要有好的设计，软件质量就 可以保证。其实我们认为代码是真正唯一可以精
确描述的设计文档。 c) 程序员的视角，编程真的很难，通过某一个项目 案例分析，20 多人一周的工作量就为几行代码 问题

第 2 单元编程价 值观
内容一：编程价值观 1. 编程的方法学 2. 什么是好的代码，我们却认为“Good code is not bad code !” 3. 编程价值观---沟通,简单,灵活 4. 价值观决定行为 5. 优秀代码的评价标准, 什么是高质量编码? 特征是什 么? 6. 软件代码的可读性 7. 代码的可扩展性 8. 糟糕代码的特征 9. 劣质代码的代价 10. 大师评价整洁代码的标准 11. 通过大量项目案例分析，什么是好的代码，对好代码 新的认识
第二篇： 编程是一种技艺-------实践篇 第3单元 高质量 函数（该内容较 多，根据实际情 况调整） 内容一：高质量函数/过程 1. 为什么需要函数 2. 函数复杂度度量 3. 函数圈复杂度以及度量 4. 函数抽象层次-单一抽象层次原则 SLAP(Single Level of Abstrction Principle) 5. 函数实现模式之—组合函数(Composed Method) 6. 万恶之源—函数过长 7. 函数的单一职责 8. 函数第一原则:是要短小,函数第二原则:是还要短小, 函数第三原则:是必须短小 9. 函数重构之道—抽取方法(Extract Method)和抽取对象 函数 10. 函数命名—怎样取好的函数名 11. 通过大量项目代码分析,函数的遇到的各种问题,如何
编程高质量函数

内容二：函数易理解与沟通 1. 函数主体流 2. 函数的异常处理 3. 函数主题流程简化方法 1-助手方法 4. 助手方法的应用场景 5. 助手方法的效果 6. 函数主题流程简化方法 2-函数对象（Method） 7. 通过真实项目代码进行分析，如果提高代码的可读性

内容三：函数灵活/易可扩展---函数接缝 1. 历史遗留代码维护问题 2. 某电信研发中心的维护问题—开发维护的效率问题。
3. 增加一个功能特性的成本并不单单是为这些功能编 码所花费时间的成本，还应该包括特性扩展的障碍成 本。 4. 代码的可维护成本分析—通过大量案例分析 a) 确定需要修改哪些部分有多难 b) 必要的改动有多少 c) 实现改动对系统其他部分的影响有多大 5. 如何实现代码的易扩展—函数接缝 6. 接缝（seam），指程序中的一些特殊的点，在这些点 上你无需做任何修改就可以达到改动程序行为的目 的 7. 通过案例分析，如何实现函数的灵活/易扩展。

内容四：函数参数 1. 函数参数过长 2. 最理想的参数数量是零,其次是一,再次是二,有足够的 理由才能使用三个以上参数. 3. 函数参数重构之道-引入参数对象(introduce parameter 4. 函数参数的顺序. 5. 不要把程序参数当做工作变量/临时变量 6. 函数参数模式-collecting parameter 7. 函数返回值 8. 通过大量项目代码是函数参数问题 9. 演示函参数的重构

内容五：变量 1. “一旦了解在程序设计中如何使用变量，他就掌握了 程序设计的精华。”-Dijkstra 2. 为什么需要变量—变量的引入的理由 3. 单一变量用途 4. 变量与方法 5. 变量作用域 6. 变量声明与初始化 7. 通过案例分析， 函数的变量如何处理与控制。


内容六：函数代码重复 1. 重复的危害 2. 强加的重复/无意的重复/无耐心的重复/开发者之间的 重复 3. 不要重复自己 DRY—Don\'t Repeat Yourself Principle 4. Make It Easy to Reuse（让复用变得容易） 5. 魔法数(Magic number) 6. 重复性代码(Duplicated Code) 7. 接口不同的相似类(Alternative Classes with Different Interfaces) 8. 系统分离关注点 9. 系统架构的基础通用服务组件 10. 通过某项目代码是介绍重复编码问题 11. 演示研发过程之中的常见重复问题,以及如何解决

内容七：条件表达式 1. 复杂表达式的简化 2. IF/ELSE 语句应该如何编写 3. Switch/Case 语句应该如何编写 4. 复杂条件表示式的危害 5. 过分深层的缩进，或者“嵌套”，已经困扰了计算机 界达 25 年之久，并且至今仍然是产生混乱代码的罪 魁祸首之一 6. 复杂表达式重构之道—引入解释变量/分解条件/抽取 方法计算条件 7. 表驱动法-多级嵌套 IF 语句的必然之道 8. 表驱动法使用总则 9. 某保险项目表驱动法应用案例分析 10. 通过大量项目代码演示条件表达式编码问题 11. 复杂表达式的注意事项,如何解决

内容八：利用多态解决复杂表达式 1. 面向对象多态技术的新认识 2. 减少使用 if 语句,重构到多态 3. 以 State/Strategy 取代类型代码 4. 引入 Null 5. 以 Command 替换条件调度程序 6. 转移聚集操作到 Visitor 7. 转移装饰功能到 Decorator 8. 通过大量项目代码演示多态可以解决的编程问题


内容九：函数组织 1. 尽管组织直线代码是一个相当简单的任务，代码结构 上的不合理会对代码的质量，正确性，可读性和可维 护性带来影响。 2. 把函数代码分成“段落” 3. 选择一个有意义的顺序，始终一致的使用它 4. 应该把代码组织得一次只做一件事情 5. 组织直线型代码。嵌套可以，但是不应该交叠 6. 系统应该由许多短小的函数而不是少量巨大的大函 数组成！ 7. 系统应该由许多短小的类而不是少量巨大的大类组 成！ 8. 把子程序提取另一个程序，不会降低整个程序的复杂 度，只是把决策点转移到其他地方。 9. 但是可以降低你在同一时间必须关注的复杂度水平。 重点是要降低你需要在头脑中同时考虑的项目的数 量，所以一个给定子程序的复杂度是有价值的。 10. 通过大量真实案例的代码进行分析函数的代码的组 织技术


内容十：函数的错误处理和异常管理 1. 函数的错误处理 2. 使用异常而非返回码 3. 依赖磁铁（Dependeny magent） 4. 主体流-明确表达控制流的主体 5. 异常流-尽可能清晰地表达异常控制流，而不干扰对主 体流的表达 6. 标准的异常处理 9 种方法 7. 通过大量真实案例的代码进行分析函数的错误处理 和异常处理

第 4 单元--高质 量函数
内容一：函数 10 个一 1. 每个变量只用于单一用途 2. 每一个行代码只表达一件事 3. 一个循环只做一件事 4. 单一抽象层次原则 5. 代码组织得一次只做一件事情 6. 函数体内只关注一种变化的原因（动机） 7. 函数应该遵守单一职责 8. 函数圈复杂应该小于一十 9. 函数第一原则是必须要短小 10. 编写函数时必须一心一意，专注，怀有谦卑的心态 8. 通过大量真实案例的代码进行分析函数的错误处理 和异常处理


第 5 单元 高质 量类（该内容较 多，根据实际情 况调整）
内容一：高质量类 1. 类的基础:抽象数据类 2. 需要用到 ADT 的场景 3. 使用 ADT 的益处 4. 基本类型依赖坏味道 5. 数据泥团坏味道 6. 案例—通过电信项目介绍数据的抽象 7. 通过大量项目代码演示数据抽象类型解决的问题


内容二：面向对象设计----职责分配 1. 单一职责原则 2. RDD-职责驱动的面向对象设计方法 3. 上帝类，代码之中的大量的上帝类 4. 通过案例分析，如何进行设计高质量类和重构

内容三：面向对象的编程 1. 上帝类/过大的类--违反单一职责 2. 依恋情结-一个方法视乎过于强调处理其他类的数据， 而不是处理自己的数据 3. 发散式改变 4. 散弹式修改 5. 消息链 6. 中间人 7. 不当的紧密性 8. 案例—通过电信项目介绍 OOP

第6单元 单元测 试与代码可测试 性
内容一：单元测试 11. 单元测试基本知识 12. 单元测试框架提供了什么功能 13. 好的测试是什么样子的 14. 为什么要写单元测试，为什么不写单元测试 15. 为什么要写\"好\"的单元测试 16. 通过案例分析单元测试的基本概念，以及如何评价好 的单元测试，单元测试为价值。

内容二：编写可测试代码 1. 如何编写可信赖的测试 2. 如何编写可维护性的测试 3. 如何编写可读的测试 4. 测试代码的重构 5. 通过大量真实项目案例分析如何编写可测试性代码

第三篇： 编程是一种习惯-------管理篇 第7单元 代码质 量度量规则 内容一：软件代码可维护性 4 个分类标准 1. 代码内部质量的核心标准 2. 可分析性（ANALYZABILITY：找到错误在代码中的 位置或者软件中必须修改的部分容易程度 3. 可修改性（CHANGEABILITY）：即要完成一个修改 需要的工作量 4. 稳定性（STABILITY）：即修改之后出问题的程度 5. 可测试性（TESTABILITY）：即能够验证修改的结果

内容二：软件代码质量 1. ANALYZABILITY = VG STMT AVGS COMF 2. CHANGEABILITY = PARA LVAR VOCF GOTO 3. STABILITY = NBCALLING RETU DRCT_CALLS PARA 4. TESTABILITY = DRCT_CALLS LEVL PATH PARA



第 8 单元 修改 遗留系统代码与 重构
内容一：修改遗留项目代码 1. 必须修改遗留的代码起因 2. 遗留代码修改危险事项 3. 如何对依赖代码做测试 4. 依赖代码的感知与分离 5. 依赖代码修改的接缝技术 6. 修改依赖代码的工具 7. 降低风险的措施 8. 接依赖技术 9. 通过多个大型项目案例分析，如何修改遗留代码，分 析如何解耦

内容二：拒绝退化-如何修改遗留系统，而不破坏现有系 统结构 1. 拒绝退化—“首先不要伤害” 2. Sprout Method 3. Sprout Class 4. Wrap Method 5. Wrap Method 6. 通过案例分析，如何修改遗留代码，而不破坏现有系 统代码结构

内容三：代码重构
1. 重构必然性 2. 破窗效应与技术债务 3. 实际重构遇到的 4 大问题 4. 介绍常见的重构技术 5. 重构到模式的目录 6. 通过多个案例分析，重构面临的问题和解决之道

第 9 AEP 自动 化错误预防

内容一：自动化预防-AEP 1. Automated Error Prevention（简称 AEP），是指通过整 个软件开发周期中自动地预防错误来提高产品质量 2. 自动化错误预防五大法则 3. 应用行业最佳实践来防止普遍错误并建立全方位的 错误预防基础---案例分析 4. 按需要修改实践来预防特殊的错误 5. 确保每个小组正确地，始终如一地贯彻执行 AEP 6. 循环渐进地采用每一个实践 7. 利用统计来稳定每一个过程，让它发挥价值 8. 通过案例进行分析，某研发中心代码自动化预防机制 建立

内容二：BugDetective 1. BugDetective 概述 2. BugDetective 规则 3. Parasoft 公司旗下产品 C Test BugDetective 分析技 术，该技术使用了几种分析技巧，包括模拟应用程序 执行路径，以识别可能触发运行时缺陷的路径。检测 到的缺陷包括，使用未初始化的内存、引用空指针、 除数为零、内存和资源泄漏。 9. 通过案例进行分析，某研发中心代码自动化预防机制 建立


第 10 单元 代 码质量体系最佳 实践
内容一：代码质量管理 4 个现代化 1. 代码管理的 4 个现代化 a) 质量量化（如何设置质量指标） b) 工具化（如何寻找合适的工具 c) 自动化（把流程自动化，忘记流程） d) 持续优化（反思与优化） 2. 多家电信研发中心，如何实现 4 个代码现代化

内容二：代码静态分析 1. 程序静态分析（Program Static Analysis）是指在不运 行代码的方式下，通过词法分析、语法分析、控制流 分析等技术对程序代码进行扫描，验证代码是否满足 规范性、安全性、可靠性、可维护性等指标的一种代 码分析技术。
2. 程序静态分析（Program Static Analysis）可以帮助软 件开发人员、质量保证人员查找代码中存在的结构性 错误、安全漏洞等问题，从而保证软件的整体质量 3. 静态分析的特点 4. 常用静态分析技术 5. 静态分析实现方式

内容三：代码静态分析工具 1. 代码静态分析工具概述 2. 以 Java 语言代码静态分析工具为例介绍，该内容的思 想仍然适合其他语言 a) Sonar 集成平台 b) CheckStyle：用于编码标准 c) PMD 的 CPD：帮助发现代码重复 d) Coverlipse：测量代码覆盖率 e) JDepend：提供依赖项分析 f) Metric：有效地查出复杂度 g) 其他语言相关代码静态分析工具 3. 通过案例演示工具在项目之中的应用

内容四：代码评审 代码结构分析、代码质量度量、代码覆盖率分析方法，代 码审查的形式、技术、技巧和流程，在代码评审环节有效 发现代码隐藏问题，代码评审具体方法和审核的具体内 容，审核效果分析，代码评审工作的组织结构设计，组织 内人员工作安排； 1. 代码评审前期准备 2. 代码评审的代码量 3. 代码评审的检查表 4. 代码评审的总结与学习

内容五：代码质量管理体系 1. 结合国内多家研发中心的代码管理经验分享 2. 代码质量体系的建立

第11持续集成与 持续检查—代码 自动化审查
内容一：持续集成 1. 版本控制库 2. ci 服务器 3. 构建脚本 4. 反馈机制 5. 源代码编译 6. 数据库集成 7. 测试 8. 审查
内容二：持续集成工具- Jenkins 1. Jenkins，之前叫做 Hudson，是一种持续集成工具，用 于监控重复持续集成的工作。 2. Jenkins 安装 3. Jenkins 配置 4. 持续代码检查

老师培训过的互联网研发企业，比如百度研发中心，阿里巴巴, 腾讯 ,畅唐科技, 猎 豹移动(原金山移动)  电信研发企业，比如思科研发中心，阿尔卡特-朗讯研发中心，华为研 发中心，摩托罗拉研发中心，大唐电信研发，广 州从兴电子，亿阳通信等。