代码质量管理
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 公用js操作归为全局外部js引用，文件内尽量使用 匿名方法，达到结构与行为分离
可维护性
• 模块清晰，容易理解
– 函数不要超过100行 – 类不要超过1000行
• 不要硬编码
– 定义常量或配置文件修改 常用属性 – Java 5 的枚举类型 – seperator()和 pathSeperator()
保持代码简洁
函数的第一规则是要短小，第二条规则是 要更短小。 我无法证明这个断言，我给不 出任何证实了小函数更好的研究结果，我 能说的是，40年来，我写过各种不同大小 的函数，我写过另人憎恶的长达3000行的 厌物，也写过许多100行到300行的函数， 我还写过20行到30行的。经过漫长的试错， 经验告诉我，函数就该小。 ——《代码整洁之道》
• 要求： 编写一个Duck类，根据不同的鸭子类型 (Mallard, Redhead, Rubber, Decoy)，实现Swim, Display, Fly 和Quack函数
实现1
• 每种DUCK各写一个类，分别实现方法。
– 有大量重复代码，复用率太低。 – 修改费力，需要大量测试。
实现2
• 建一个DUCK父类，实现公共方法。 • 各种不同的DUCK继承父类，若实现不同， 则覆盖父类中的方法。
同行评审（PEER REVIEW）
• 何时：桌前检查之后 • 谁：若干程序员和测试人员、设计人员组 成一个会审小组
• 做什么：讲解、阅读、讨论和争议，对程 序进行静态分析的过程
• 目的：促进开发人员、测试人员之间的交 流，发现源代码中的缺陷
动态单元测试
• • • • • 思考： 我们为什么不爱写单元测试？ 单元测试真的有用吗？ 测多少才算够呢？ 如何写单元测试？
• 重构并不是重写，重构可以改进程序的内 部结构，从而提高代码体的可维护性。
– 改进代码美观度 – 快捷寻找BUG – 提高开发速度 – 改进源码可读性 – 增加程序的可扩展性
修改代码的两种方法
重构的驱动力
• 软件开发的现实：时间紧，任务重，变化 频繁，客户难伺候。 • 有时，为了达到一些目的（商业或非商 业），我们不得不在需求没有完全确定的 情况下，开始设计。 • 初始设计不充分或是跟不上需求的变化。 • 编码不符合规范，缺少注释，质量低下。 • 频繁打补丁，维护成本不断升高。
代码质量管理
陶嘉驹 2011/09
自我介绍
• 6年工作经验，主要从事J2EE系统开发、测 试及构建工作。 • 对Web系统开发，自动化测试以及构建技 术有较为深刻的理解。 近年来致力于软件 质量保证及过程改进。 • E-mail：tjjhz@163.com
议程
• • • • • • • 理想与现实 是谁把代码变烂 什么是好的代码 提升代码质量的方法和工具 代码质量的衡量 重构 讨论
– JUnit – TestNG – CPPUnit
修复BUG的成本
功能/性能测试工具
• IBM Rational Functional Tester • HP Quick Test Pro • Selenium (Open Source) • IBM Performance Tester • HP WinRunner/LoadRunner 11.00 • Jmeter/Grinder (Open Source)
理想与现实
软件缺陷的引入
• 世上本没有BUG • 随着功能的增加，便有了BUG • 老的BUG改了，可能引入新的BUG • 事实1： 我们的软件，在发布前，其实就 已经百病缠身了。
烂代码的伤害
发现、修改和预防烂代码
• 疑问1：我们如何发现烂代码？ • 疑问2：烂代码要不要改呢？应该怎么改？
– 但愿客户不要发现…… – 不影响功能，反正用户也看不到，不要改了 – 时间来不及了，我们下个版本再说吧
• 项目透明 • 团队共享 • 构建自动化
HUDSON 首页
思考
• 什么是重构？什么情 况下代码需要重构？ • 重构有哪些好处？ • 重构有哪些基本方法？ • 如何重构你的代码？
什么是重构？
• 所谓重构(refactoring)是这样一个过程：在 不改变代码外在行为的前提下，对代码做 出修改。
• STAF Framework
JUNIT 测试覆盖率
JUNIT 测试覆盖率
集成看板 – SONAR
Apache Tomcat Memo: http://nemo.sonarsource.org/dashboard/index/50544?page_id=2
持续集成与每日构建
• 持续集成
– 持续编译 – 持续测试 – 持续整合
可变更性
• 代码复用 • 设计模式
• • • • • 单例模式 工厂模式 策略模式 复合模式 MVC
• 设计原则
提升代码质量：途径 + 步骤
单元测试
• 什么是单元测试？ • 单元测试是针对软件设计的最小单位——程序 模块，进行正确性检验的测试工作。 • 目的 发现每个程序模块内部可能存在的差错 • 测试范围 • 模块接口、局部数据结构、边界条件、独立 的路径和错误处理
单元测试
• 测试依据：详细设计
• 执行者：开发人员/白盒测试人员 • 步骤：
– 先静态检查分析 – 再动态运行代码，检查执行结果
静态分析工具
• PMD/FindBugs (Eclipse) • CheckStyle (Eclipse) • DevPartner （支持VS + Eclipse） • 建议：在代码Check-in之前自己先做好静态 测试和桌前检查。Check-in就是要先Check 再In。
代码重构的基本技术
• 双重否定表肯定
– Example1.java
• 分解复杂判断、拆分函数
– Example2.java
• 引入契约式设计
– 对输入和输出进行验证，以确保系统不会出现 我们所想象不到的异常和得不到我们想要的结 果。
• 使用多态代替条件判断 (Stock) • 恰当的使用设计模式
代码重构实例 —— DUCK
• 疑问3：如果烂代码不是先天性的，那是不 是可以预防？
是谁把代码变烂？
*大泥球 (Big Ball of Mud)，是指杂乱无章、错综复杂、邋遢不堪、随意拼 贴的大堆代码
制约程序员编写高质量代码的因素
• • • • • • • 对需求和设计的理解不透彻 对软件业务流程不熟悉 没有开发经验，不知道怎样的代码是好的 对开发工具或开发语言不熟悉 缺少监督体系或不重视质量评估 受情绪因素的影响等因素 其它非代码因素也起着关键作用
– 很多方法在子类中都要重写，效率不高。
策略模式 (STRATEGY PATTERN)
• 什么是设计模式？
– 模式不是代码，是历经验证的OO设计经验 – 大多数模式都着眼于软件变化的主题 – 模式不是被发明的，而是被发现的
• 什么是策略模式？
– 策略模式定义了算法族，分别封装起来，让它 们之间可以互相替换，此模式让算法的变化独 立于使用算法的客户。
设计原则
• 设计原则1：找出应用中可能需要变化之处， 把它们独立出来，不要和那些不需要变化 的代码混在一起。 • 设计原则2：针对接口编程，而不是针对实 现编程。 • 设计原则3：多用组合，少用继承。“有一 个”可能比“是一个”更好。
回顾
• • • • • • • 理想与现实 是谁把代码变烂 什么是好的代码 提升代码质量的方法和工具 代码质量的衡量 重构 ห้องสมุดไป่ตู้论
注释的要求
• 1、文件头标注开发者、功能、开发时间、最后修 改时间、修改详情； • 2、方法头标注功能、输出参数、输入参数； • 3、方法体内重要代码及疑难代码行内注释； • 4、if else类代码优先考虑标注，标注在右大括号 之后； • 5、数据成员、数据操作分组，两者之间空一行区 分； • 6、方法之间空一行； • 8、采用垂直对齐，tab缩进，以保证代码上下整 齐； • 9、嵌套（如if else及for）一般不要超过三层；
推荐资料
• 《高质量C++/C编程指南》 • 《代码简洁之道》 • 《Head First - Java设计模式》
讨论
WEB开发中HTML的格式
• 普遍采用xhtml格式规范，并额外附加 • 除</head>与<body>之间空一行外其余无空行； • 标记垂直对齐加tab缩进，同一行字符过多情况下 可将同一级标签换行； • 数据显示使用table，布局使用div，写好全局css样 式引用，避免行内书写css，达到结构与样式分离；
破窗理论
破窗效应
好代码的特性
1
2 3
4
• 可读性 • 可维护性 • 可变更性 • 正确性
可读性
• 代码整洁、规范
– – – – 变量、方法命名规则 代码样式，缩进与换行 使用Eclipse的Format 举例
• 写好注释和文档
– 注释也需要规范 – 自动导出Java Doc
（详见Java编程规范）
桌前检查（DESK CHECK/SELF REVIEW）
• 何时：程序通过编译之后，进行动态单元 测试之前 (在跑完静态测试之后，因为工具 可以帮我们做掉很多事情。) • 谁：程序员自己 • 做什么：对源代码进行分析、检验，并补 充相关文档，根据《编码规范》编写或调 整自己的代码符合编码规范 • 重点：工具无法覆盖到的问题
你写过、见到过这样代码吗？
主动重构与被动重构 - MAKE THE CHANGE
• 顾客想要一些新功能，他们决定更改现有 的做法。 • 必须升级现有版本以支持WIN7，不然用户 将无法使用。 • 应对技术改变，我们必须更新代码，以便 适用于新的协议。(Wap, Cloud…) • 我们学到了新的设计方法，能够使现有系 统变得更好。 • ……