代码整洁之道-卓越软件代码质量体系最佳实践

更新时间:2023-07-21 13:33:01 阅读量: 实用文档 文档下载

说明:文章内容仅供预览,部分内容可能不全。下载后的文档,内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的,是否完整无缺。

代码整洁之道-卓越软件代码质量体系最佳实践

课程简介:

管理者最担心听到开发人员这样抱怨:“不能再增加功能了!我们得停下来重写代码。代码库一团糟,就像纸糊的老虎,根本应付不了持续增加的用户。我们维护不下去了!”

这一幕在很多公司上演过,现在依然在不断重演。一旦公司陷入这种困境,以前版本的开发者往往沦为替罪羊。新的开发者一般就会骂前人怎么写这么烂的代码。他们准备推倒重来,准备重写系统。在重写代码的过程中,用户无法看到产品的任何改进。你可能认为重写代码至多也就几个月,但是实际花费的时间无一例外要多得多。你只能坐在一旁,眼睁睁看着用户投奔竞争对手,而这个时候,竞争对手恰恰在不断地改进产品。

因此我们认为软件质量,不但依赖于架构及项目管理,而且与代码质量紧密相关。这一点,无论是敏捷开发流派还是传统开发流派,都不得不承认。干净整洁的代码,既在质量上较为可靠,也为后期维护、升级,架构演进奠定了良好基础。在最近几年的业界,大家都把精力花费在了软件需求,架构,过程和管理等,反而代码构建这个与软件开发骨肉相连的环节反而被忽视了. 我们认为”代码是债务而不是资产”。最开始,团队会编写代码,做出产品,并用它来赚钱,但是,之后团队应该尽可能地寻找减少代码的方法和使代码尽量整洁,从而降低成本。软件界有一个真理,你拥有的代码越多,添加新内容所要付出的成本就越高。更坏的情况是,你所添加的所有内容都会堆在代码的顶端,接下来要添加内容的时候会成本会更高。如果你的代码结构越好,你做了越多的单元测试,你使用的数据库模式越好、越小、耦合越松,那么添加新代码所需要付出的成本就越少。因此OOP大师 Craig Larman: “最好维护的代码就是没有代码,好的程序员的代码产量是负的,因为他通过减少代码来增加功能”。对比现实中,很多人以为,LOC(line of code)越多的feature越大,写LOC越多的程序员越牛。这其实是极其错误的观念.

因此我们必须有全面的管理制度让我们保持代码少而整洁。所以软件大师Michael Feathers认为"未来属于知道如何有策略地删除代码的公司”。持有代码的成本要比我们想象的大。意识到这一点的公司更具有竞争优势。

为了切实帮助软件企业降低企业项目开发成本,大面积提高软件工程师编程能力和代码质量管理能力,我们特别推出了实战训练营. 分享多家大型研发中心代码管理经验给大家。

该课程适应于各个阶段的开发群体.初级工程师能够透过大师的眼睛来看待编程,了解编程的价值观和原则;具有丰富经验的设计师和架构师可以通过模式进行反思,探究成功实践背后的意义.把价值观,原则和开发实践结合;管理者通过学习业界著名研发中心的管理经验和失败的教训,来制定自己公司的代码管理策略。

培训讲师:刘捷 -- 曾任BEA中国专业服务部 高级技术顾问

2000年加入BEA中国区专业服务部,任高级技术顾问,主要负责BEA客户项目的架构设计和项目开发,技术支持。保证项目的成功实施,运行,维护。参加过全省、全国多个大型的计算机应用项目,设计的领域包括电信,银行、税务,社保等等。 技术能力:

DB,UNIX,J2EE,SOA,WebLogic Server, WebLogic Integration, WebLogic Portal相关的架构设计。

Day1

第一篇: 编程是一种态度-------编程价值观 内容一:代码是债务 - 代码的认识---代码就是债务 - 代码是债务,越少越好 - 你拥有的代码越多,添加新内容所要付出的成本就越高 - 通过案例分析让代码库尽可能小的方法: 尽可能创建通用的工具。 删除不用的代码或者特性。 确保项目模块化,并分割成相互没有关联的子项目。 熟悉你经常使用的代码库。

第 1 单元 代码就是债务

对代码库的规模时刻保持警惕,保持它是小而敏捷的。 通过国际研发中心电信计费系统演示代码是债务的思想,10 多年国外研发团队 设计与研发第一版本,目前几百人在维护 通过项目演示通过重构如何减少了一半的代码,维护的人员的减少 项目的失败可能归咎于各种各样的原因。一些项目因糟糕的需求而失败,另一些 则由于钱和时间超支了,还有少数单纯是因为糟糕的管理所致。如果我们探究其 根本原因,是否会发现所有项目失败的罪魁祸首是糟糕的代码呢? Bob 大叔坚信糟糕的代码所带来的成本之大足够让一个项目失败。 内容一:编程价值观 1. 编程的方法学 2. 编程价值观---沟通,简单,灵活 3. 优秀代码的评价标准, 什么是高质量编码? 特征是什么?

第 2 单元 编程价值观

4. 软件代码的可读性 5. 代码的可扩展性 6. 糟糕代码的特征 7. 劣质代码的代价 8. 大师评价整洁代码的标准 通过某项目代码是演示糟糕的代码,以及经过重构之后的代码,进行对此.

Day2

第二篇: 编程是一种技艺-------编程实践篇 内容一:高质量函数/过程 为什么需要函数 函数复杂度度量

第 3 单元 高质量函数

函数圈复杂度以及度量 函数抽象层次-单一抽象层次原则 SLAP(Single Level of Abstrction Principle) 函数实现模式之—组合函数(Composed Method) 万恶之源—函数过长 函数第一原则:是要短小,函数第二原则:是还要短小,函数第三原则:是必须短小

函数重构之道—抽取方法(Extract Method)和抽取对象函数

函数命名—怎样取好的函数名

通过大量项目代码分析,函数的遇到的各种问题,如何编程高质量函数 内容二:函数代码重复

重复的危害

强加的重复/无意的重复/无耐心的重复/开发者之间的重复

不要重复自己DRY—Don't Repeat Yourself Principle

Make It Easy to Reuse(让复用变得容易)

魔法数(Magic number)

重复性代码(Duplicated Code)

接口不同的相似类(Alternative Classes with Different Interfaces) 系统分离关注点

系统架构的基础通用服务组件

通过某项目代码是介绍重复编码问题

演示研发过程之中的常见重复问题,以及如何解决

内容三:函数参数

函数参数过长

最理想的参数数量是零,其次是一,再次是二,有足够的理由才能使用三个以上参数.

函数参数重构之道-引入参数对象(introduce parameter object

函数参数的顺序.

不要把程序参数当做工作变量/临时变量

函数参数模式-collecting parameter

函数返回值

通过大量项目代码是函数参数问题

演示函参数的重构

内容四:变量

变量定义常见的错误

变量的数据类型

变量的初始化原则

变量的作用域

变量的持续性

变量的绑定时间

数据类型和控制结构之间的关系

变量的命名

全局变量

通过大量项目代码演示变量相关问题

演示变量的注意事项

内容一:条件表达式

IF/ELSE语句应该如何编写

Switch/Case语句应该如何编写

复杂条件表示式的危害

过分深层的缩进,或者“嵌套”,已经困扰了计算机界达25年之久,并且至今仍然是产生混乱代码的罪魁祸首之一

复杂表达式重构之道—引入解释变量/分解条件/抽取方法计算条件

表驱动法-多级嵌套IF语句的必然之道

表驱动法使用总则

某保险项目表驱动法应用案例分析

通过大量项目代码演示条件表达式编码问题

复杂表达式的注意事项,如何解决

内容二:利用多态解决复杂表达式

面向对象多态技术的新认识

减少使用if语句,重构到多态

以State/Strategy取代类型代码

引入Null Object

以Command替换条件调度程序

转移聚集操作到Visitor

第4单元 转移装饰功能到Decorator

复杂表达式与循通过大量项目代码演示多态可以解决的编程问题

环语句 内容三:防止变异

防止变异-如何设计函数,对象,子系.使其内部的变化或不稳定性对其他元素元素产生不良影响

接口,多态,数据封装、间接性和标准都是源于PV

开闭原则

数据驱动(Data-Driven Design)编程

元数据或反射驱动(Meta-data or Reflective )编程

复杂业务逻辑-解释器驱动编程

案例—通过电信项目介绍如何设计应对变化

通过大量项目代码演示多态可以解决的编程问题

内容四:循环控制

选择循环的种类

循环控制

循环的创建-有内向外

循环与数组

递归

Goto语句

控制结构与复杂度

案例—通过电信项目介绍如何设计应对变化

通过大量项目代码演示多态可以解决的编程问题

内容一:类基础-数据抽象类型(Abstract Data Types)

类的基础:抽象数据类

需要用到ADT的场景

使用ADT的益处

基本类型依赖坏味道

数据泥团坏味道

案例—通过电信项目介绍数据的抽象

通过大量项目代码演示数据抽象类型解决的问题

内容二:数据封装

数据封装

数据的访问

第5单元 类的封装

高质量类设计与通过大量项目代码演示数据封装

编码 内容三:面向对象设计与编程核心----职责分配

单一职责原则

RDD-职责驱动的面向对象设计方法

内容四:面向对象的编程

上帝类/过大的类--违反单一职责

依恋情结-一个方法视乎过于强调处理其他类的数据,而不是处理自己的数据 发散式改变

散弹式修改

消息链

中间人

不当的紧密性

案例—通过电信项目介绍OOP

Day3 第三篇: 编程是一种习惯-------管理实践篇

内容一:代码重构

重构必然性

实际重构遇到的4大问题

如何发现重构点

如何去重构(重构方式)

如何知道重构何止截止

如何保证重构的正确性

介绍常见的重构技术

第6单元

代码改善 重构到模式的目录 内容二:代码测试

代码测试

代码测试的技巧集锦

代码测试的典型错误

改善测试过程

内容三:代码调试

代码调试

寻找代码缺陷

调试的心里因素

调试工具

内容四:修改遗留项目代码的艺术 必须修改遗留的代码起因

遗留代码修改危险事项

如何对依赖代码做测试

依赖代码的感知与分离

依赖代码修改的接缝技术

修改依赖代码的工具

降低风险的措施

接依赖技术

内容一:代码质量度量

代码质量的度量

业界其他度量标准

通过分析多个实际项目,分别度量相关是否标准 内容二:代码静态分析工具

代码静态分析工具概述

以Java语言代码静态分析工具为例介绍 CheckStyle:用于编码标准

PMD 的 CPD:帮助发现代码重复

第7单元

代码管理 Coverlipse:测量代码覆盖率 JDepend:提供依赖项分析

Metric:有效地查出复杂度

其他语言相关代码静态分析工具

通过案例演示工具在项目之中的应用 内容三:代码评审

代码评审前期准备

代码评审的代码量

代码评审的检查表

代码评审的总结与学习

内容四:代码管理

结合国内多家研发中心的代码管理思路分享

本文来源:https://www.bwwdw.com/article/dxym.html

Top