java代码分析及工具分析.docx

一个项目从搭建开始，开发的初期往往思路比较清晰，代码也比较清晰。随着时间的推移，业务越来越复杂。代码也就面临着耦合，冗余，甚至杂乱，到最后谁都不敢碰。作为一个互联网电子商务网站的业务支撑系统，业务复杂不言而喻。从09年开始一直沿用到现在，中间代码经过了多少人的手，留下了多少的坑，已经记不清楚了，谁也说不清了。代码的维护成本越来越高。代码已经急需做调整和改善。最近项目组专门设立了一个小组，利用业余时间做代码分析的工作，目标对核心代码进行分析并进行设计重构。　代码分析如果用人工来做，需要两点：1、开发人员代码造诣要求很高。2、开发人员投入时间成本非常大。然而现在网络上 Java代码分析工具做的比较好。所以考虑开始利用这些工具对代码进行分析，并做修改。当然最好在最后有个资深人士做相关的review或开发人员自检。先考虑工具吧，工欲善其事，必先利其器。所以决定search一下，代码分析和代码分析的工具，便于更好的利用和进行。　学习一下并做一些归纳： 提到静态代码的概念：个人理解为 不需要运行起来的代码所关注的点。就是就代码看代码，语法、结构、接口、类等。　整个软件开发生命周期中，网上说30% 至 70% （占有量还是很大的）的代码逻辑设计和编码缺陷是可以通过静态代码分析来发现和修复的。看来效果还是很明显的。　静态代码分析的好处，的确有很多好处：　1. 帮助程序开发人员自动执行静态代码分析，快速定位代码隐藏错误和缺陷。　2. 帮助代码设计人员更专注于分析和解决代码设计缺陷。　3. 显著减少在代码逐行检查上花费的时间，提高软件可靠性并节省软件开发和测试成本概念不多提了，看工具：工具目的检查项FindBugs检查.class基于Bug Patterns概念，查找javabytecode（.class文件）中的潜在bug主要检查bytecode中的bug patterns，如NullPoint空指针检查、没有合理关闭资源、字符串相同判断错（==，而不是equals）等PMD检查源文件检查Java源文件中的潜在问题主要包括：空try/catch/finally/switch语句块未使用的局部变量、参数和private方法空if/while语句过于复杂的表达式，如不必要的if语句等复杂类CheckStyle检查源文件主要关注格式检查Java源文件是否与代码规范相符主要包括：Javadoc注释命名规范多余没用的ImportsSize度量，如过长的方法缺少必要的空格Whitespace重复代码1、findbugs：　安装：/projects/findbugs/　看使用体验：针对一个项目启动findbugs，会进入findbugs的工作视图 如上图　蓝色区域：罗列出了findbugs在代码中检测到的代码问题。同样的红色为严重的，黄色为警告。　由于自己写的学习项目所以代码不庞大，质量也还行，所以检测出来的都是黄色警告的。　紫色区域：点击对应的检测点，能定位到问题代码具体的位置，并且在左边有个bug虫子给出具体问题的信息　绿色区域：对应左边蓝色区域的检测点，给出的详细描述和建议。 个人觉得findbugs对于代码检测的深度力度要更好。比如，子类名和父类名相同，死存储（没有调用却开辟空间的），一个方法没有对参数对象验证空等等。　对代码的质量检查做的很到位。而且很清晰。当然findbugs 也有自定义的设置，个人觉得现有功能已经很好用了，不需要自定义。2、Checkstyle ：　安装：/projects/eclipse-cs/files/latest/download下载插件，links plugin的方式安装到eclipse中　重点看使用体验：针对一个项目启动checkStyle之后　刚检测完，项目所有类都泛黄，甚至有的类打上了小红叉。静心仔细的看下：　提示有：public修饰符多余，一行超过80个字符，缺少文档注释，魔法数字等等等等。出现中文代码的地方会直接打红叉。非常精细。　蓝色区域：包括Errors和warnings。Errors重点列出了代码中的问题，比如代码中有中文等等，Warnings：一般是代码风格不好的地方。比如代码　最后一行加注释算是不好的风格　紫色区域：发现用于特定的注释分割，很多注释都有问题，和eclipse自动格式化有冲突，我觉得可以是忽略的。左边的小放大镜有详细的不规范信息。　个人觉得检查的精度还是很细的，但是对于注解等的检测过于精细，很扰乱视眼。Errors级别就可以了。和eclipse的格式化有很多的冲突。导致很多也是不必要的检验。　当然，也是可以自定义设置检测项，如下： 　这样可以把注释的或者和日常格式化有问题的检查撤销掉。主要检查代码的问题。不过说实话这个设置起来还是很麻烦的，我觉得还不如将就着看所有的提示　信息。不需要