静态分析概念已经提出多年而在过去几年里利用该工具评估和诊断代码技术已日趋成熟几乎每种语言都存在相应软件Software审查工具这些审查可以在多个领域如循环编码风格设计复制代码命名风格性能等领域中隔离出不良代码而在每个层级中又存在另套完整审查可供员使用

　　这里要提醒大家员可能会因审查报告过多漏洞而感到厌烦笔者曾经看到过个有20万行应用用现在标准来衡量这当然不算多此外还运行了200+审查该报告列出了35万个需要修复违规的处这样以来确是有些麻烦

　　要想成功使用审查关键是要限定审查套组量这个量视情况而定员应该把握好这个量才能事半功倍

　　我们通常会推荐员和其团队(Team)从小有限审查开始先修复各种常见问题

　　审查最令人激动点是它可以为我们提供代码信息以及代码构成仅报告指出某行出现异常这并不意味着它就是真正问题所在个好工具应该能够将所报告问题做上已验证标记;可以在注释中标明这样审查工具就明白该区域已经被查看过了

　　那么什么时候可以使用审查呢?建议每晚或进行整合构建时候都可以运行审查以便保证运行尤其是当代码编写不够严格或刚刚编写完不久情况下运行已有代码中Software Archeology时至少应该运行次代码而重构进程时候则要直运行审查

　　本文介绍 5个审查工具分别是Numerical Literal in CodeString LiteralGod MethodShotgun Surgery和Duplicate Code

　　Numerical Literal in Code

　　这是最简单重构思路方法的我们已经写出这样代码:

　　double salaryCalc(double salary){

　　 salary*1.34564333721

　　}

　　C

　　两个月后我们要更新salaryCalc思路方法而客户查看代码时候则遇到了困难很可能他们不记得思路方法最开始写法了所以不明白1.34564333721代表着什么最好是用常量来代替数字这样就赋予了数字有意义名称如下所示:

　　double salaryCalc(double salary){

　　Return salary* BONUS

　　}

　　Static final double BONUS = 1.34564333721

　　C

　　当员查看现在这个代码时他们至少明白1.34564333721代表是什么如果你要重构单元测试不应该发生改变而重构完成后结果应该还样

　　String Literal

　　我们都知道时间紧迫时候我们可能要改变代码并使其能尽快投入运营String Literal就派上用场了该审查特别适用于要将软件Software国际化任务需要经常运行该审查单元测试不应发生改变结果也要保持致

　　这个不正确:

　　public const helloWorldMessage: String = ‘Hello World!’;

　　Delphi

　　这个才正确:

　　Public const helloWorld Message: String =

　　resourceManager.GetString(‘msg.helloworld’);

　　Delphi

　　这个思路方法将会对应用外能够被改变资源包中helloWorldMessage串进行检索并在不重新编译情况下进行更正

　　God Method

　　God ‘X’审查‘X’相当于MethodClass该审查不仅仅是查看代码然后指出不足

　　对这类审查概括可整理总结为god Method;简而言的我们拥有个类这个类包含了50个思路方法但是只有个思路方法恰好能完成所有工作那么这个思路方法就要被标记为god Method

　　顺便说下大多数god ‘X’情况都不是这样开始在god Methods情况中它们通常会以常规简单思路方法开始但是随着时间推移功能越来越多思路方法要负责方面也越来越多因此慢慢成为了功能齐全God Method

　　那么什么样计算用于指明哪种思路方法比其他思路方法功能更多呢?通常计算所涉及 3种主要审查和套代码都是用于确定其状态这 3种审查包括Long MethodsLong Parameters和Switch语句 4种基本代码包括:编码行参数量本地变量数以及分支指令最大数

　　把这些数放在起就可以看到计算是如何运行Long Methods通常意味着执行个以上操作Long Parameters较难理解Switch语句代表代码中区别路径通过在编码行加入要和其他思路方法进行对比思路方法然后验证参数量本地变量数以及分支指令最大数它就可以计算出到底哪个才是Gog Method

　　当我们分离出God Method后又该如何办呢?这时候会产生许多重构器如Extract MethodIntroduce Parameter Object等目是要确定该思路方法按照预计方式在执行

　　Shotgun Surgery

　　该审查是笔者最喜欢审查的不仅是它名字很酷还它可以帮助员节约大量时间和god ‘X’审查样该思路方法也使用代码来计算其结果

　　大家有没有尝试过用需要修改行代码来隔离个思路方法呢?如果使用shotgun surgery审查将节约很多时间该审查会查看代码中依赖某思路方法位置这意味着你将知道某行更改将改变整个代码基础你最好是在更改代码行的前仔细考虑清楚

　　要用来帮助shotgun surgery思路方法进行计算另外两个思路方法分别是Changing Methods和Changing ClassesChanging 思路方法审查是紧密相关思路方法数Changing 类是更改思路方法时候受到影响类因此可以将shotgun surgery审查视为依赖于小型思路方法检查



　　所以如果你所拥有思路方法中包含了shotgun surgery该如何办?很简单看清楚代码找到下属小型思路方法然后查看预定更改要对系统做些什么操作

　　Duplicate Code

　　曾几何时笔者认为 复制/粘贴 功能应该从编辑器中清楚我们使用这功能频率令人吃惊这种思路方法导致我们复制了大量不良代码

　　而复制不良代码所带来最严重问题就是维护了使用这个审查我们要能够寻找到那些只做过稍微修改代码很多工具在审查返回信息前会介绍说明有十行或更多行代码需要被复制推荐大家将复制数量设置降到 3或 4行

　　旦员隔离出复制代码那么组标准重构思路方法就可以发挥其作用通常Extract Method或Pull Up Field可以做到这点

　　如下所示个这样If语句:

　　 ( x=0; x< 100; x{

　　//other statements

　　someValue = 10;

　　} {

　　//other statements

　　someValue = 10;

　　}

　　Java

　　可以写成这样:

　　 ( x=0; x < 100; x{

　　//other statements

　　} {

　　//other statements

　　}

　　someValue = 10;

　　Java

　　这简化举例很好地展示了其效果;someValue每次都会改变成10

　　现在有很多审查可供选择记住当你要开始审查时候先选择小点和那些能快速给出反馈信息

　　审查是员容易忽视工具花些时间找到些适合自己审查将会节省很多开发时间