最有用的就是空指针，比如方法接受一个参数，直接就使用了，并没有判断是否为 null，这种只要前端没做相应的参数校验，就很容易出 bug

你们引入代码静态分析的目的是什么，想解决什么问题？不能解决你们的问题完全可以不用呀

有用，不过不是很明显，代码质量有提升。扫出来的 bug 有些现在不影响功能，但是以后是坑（有些问题可能一些人不重视，一些人特别看重，比如信息泄露什么的）。
引入静态工具是 QA 衡量代码质量的一种方式，一般和研发基础要求相关，要不要用得看项目实际情况。毕竟有些项目可能连测试都没。

说一下我们引入静态工具的进展，今天找开发看了一下扫描出的问题，其中确实有部分值得开发一改的。
目前计划是在开发提交完版本代码到测试之后，开发扫描一下自己看看做自检。

开发懒的把代码写的特别规范其实也能提升效率

如果现阶段整个团队是这样的共识，那引入意义不大。静态分析工具原理是词法分析，类似于 idea 常见的各种波浪线提示，过程中也许会发现一些写法不规范引起的、藏得比较深的异常路径 bug（比如最常见的检查做得不够引起空指针），但如果大家觉得只要测试是通过的，这些问题不处理也关系不大的话，那还不到引入的时机。在业务稳定且确认要长期发展，对质量要求更高了也愿意投入更多时间精力去处理一些短期够用长期是大坑的技术债，才适合引入。

另外，引入的时候要注意做下规则筛选，有些 “政治正确” 但实际不会引发问题的规则（比如创建的变量没用）可以先去掉，只保留会引起 bug（如没有有效判空、异常被捕获导致事务回滚无效）的规则。扫描结果逐步得到开发认可后，就可以配合 sonar 提供的质量阈，做到提测前要求扫描并且质量阈结果必须通过。

老大让搭建的 sonarqube+Jenkins 集成，搭建完成后对代码进行扫描，感觉 sonar 扫描出来的问题意义不大，哈哈

有效果，但其中的收益就得看怎么衡量了。挺巧，上层也让我们给公司的开发团队引入 sonar，已经弄了几个月了，让我们选几个 “标杆项目” 来接入，当然也支持云效、jenkins 方式接入。

至于这个效益，也得从开发角度去看，就是扫出来的问题，我是否有必要去修改？我改了和不改的区别是什么？有什么风险？所以得先让开发他们认可你的规则，认可出现的问题，毕竟是增加工作量的事。

既然要认可，那就得弄清楚他们关心的问题是什么。举个例子，其中有个团队比较重视安全方面的问题，那就使用安全的规则去扫，再尝试着去修复问题，看下后期测试环节中的问题是否比以前少，这就能体现效益。而且 sonar 的规则只能从插件下载中获取，如果开发需要的规则是插件中没有的，则需要在插件的基础上二次开发，实现自定义规则。参照这个方法：https://www.jianshu.com/p/b849175dd38b， 最后打包放进/plugins 目录中重启即可

还有一点，如果开发是在不愿意改。可以尝试由上往下，让他们的领导重视代码审查工作，这样的执行力更有效。毕竟我们也是按要求办事一方

公司上层也是出于提高代码质量的方向出发，让大家有个统一规范的目的（老实说，这点不实际，毕竟各团队做事、编码风格不一）

https://testerhome.com/articles/16784
很久之前写过一篇内容，大家遇到的问题应该类似，你可以看看