目前一直在安装愉悦师兄与路遥师兄的指示下研究算法、做实验,在尹老师、王涛师兄的指导下一直在研究对项目代码质量的评估。
进展如下:
1、阅读了师兄们给的论文,首先确定了寻找在项目开发中的bug_introduced 与 bug_fix的相应的commit,算法的流程主要安装路遥师兄给的论文中的模型来做实验,同时由于愉悦师兄已经在这个方面有过很好地基础,我们在理解吃透余悦师兄的代码基础上,继续做实验,算法的流程图如下:
2、基于第一步的实验结果,我们继续提出了运用sonar来具体扫描bug_introduced_commit 与 bug_fixed_commit相应的文件,寻找其中具体的代码行的issue(代码质量缺陷)以此来推断sonar_isssue与相应的bug之间的关系,在上一周我已基本实现代码(python),但是由于时间比较仓促,代码还是有很多bug,上周末我花了两天的时间重构了代码,目前已经将代码上传到trustie,让师兄进行审阅,对实验结果初步的分析后发现,代码的方法复杂度过高,运用switch 等代码会导致比较多的bug。
问题与展望:
1、我打算将代码质量的优化还需要进行,目前在用sonar扫描具体文件时,花费的时间还是太多,整体的时间还是不够理想(目前的实验只是初步对一个项目进行了测试,如果是上百个项目的数据量可能时间不是很理想)
2、在得到sonar的具体的代码缺陷与用git得到具体的bug后,我对下一步的研究还是有点迷茫,打算还是和余悦、路遥师兄继续多交流。
3、这周的任务还是要先将目前的实验结果都跑出来,在继续分析
尹 刚 写到:尹老师,这个度量是路遥师兄提出来的,5种分类是sonar自身就有的1. BLOCKER(10 scores)2. CRITICAL(7 scores)
3. MAJOR(5 scores)
4. MINOR(2 scores)
5. INFO(1 score)
这个度量是谁提出来的?
1. BLOCKER(10 scores)2. CRITICAL(7 scores)
3. MAJOR(5 scores)
4. MINOR(2 scores)
5. INFO(1 score)
这个度量是谁提出来的?
尹 刚 写到:恩,尹老师 , sonar的issue种类主要分为
sonar分析得到的issue包括哪些种类?不同种类的issue应该和bug的关系是不一样的。
1. BLOCKER(10 scores)
Bug with a high probability to impact the behavior of the application in production: memory leak, unclosed JDBC connection, .... The code MUST be immediately fixed.
2. CRITICAL(7 scores)
Either a bug with a low probability to impact the behavior of the application in production or an issue which represents a security flaw: empty catch block, SQL injection, ... The code MUST be immediately reviewed.
3. MAJOR(5 scores)
Quality flaw which can highly impact the developer productivity: uncovered piece of code, duplicated blocks, unused parameters, ...
4. MINOR(2 scores)
Quality flaw which can slightly impact the developer productivity: lines should not be too long, "switch" statements should have at least 3 cases, ...
5. INFO(1 score)
Neither a bug nor a quality flaw, just a finding.
目前先把数据跑出来,在进行下步分析issue与bug之间的关系,代码那块问题已经不大
余 跃 写到:恩恩,好的师兄尹 刚 写到:尹老师高瞻远瞩!!我也希望能随时方便的使用sonar
同时,请注意将sonar封装因为一个简单的api,这样大家都可以调用。不用每个人都重复这个工作。