优秀的团队为了保证可读性、可维护性、避免重复踩坑与保证代码质量，都会推出一些开发规范来遵守。开发规范是前置主动要求团队成员遵守的，而光靠意识是难以保证完全遵守规范的，所以还需要一些工具辅助。当然即使有工具做这些事情，规范也是必须推广的，让大家先仔细读读，毕竟直接写出优秀的代码是最好的，然后再辅助工具乃最佳实践。
开发规范
一流公司制定规范，二流公司申请专利，三流公司生产产品。所以目前公开规范的大多是大厂的规范。
目前知道大厂公开的Java开发规范
Google开发规范 github markdown格式 点我查看
阿里巴巴开发规范 PDF格式 点我查看最新版
华为开发规范
Oracle开发规范
阿里巴巴的开发规范，虽然不是单纯的规范，还包括了开发中的各种坑从主观上的一些强制规定，但是总体上还是很有用的，可以拿来部分or全部直接执行。
独立的组件
1. FindBugs
只寻找可能存在bug的地方，不注重样式或者格式，它试图只寻找真正的缺陷或者潜在的性能问题。
特点
基于class分析，如果你clean了再去执行发现没有执行生成报告，所以需要编译后才能执行分析
有maven插件，有IDE插件（eclipse插件，也有idea插件）
开发时不用使用maven插件，要编译执行检测生成xml然后再生成网页查看结果，挺麻烦。如果要与Jenkins集成的时候，maven插件就有用了，集成方式点我
开发时使用IDE插件非常方便
插件中Bug Explorer 中的灰色图标处为 Bug 类型，红色图标表示 bug 较为严重，黄色的图标表示 bug 为警告程度
代码缺陷分类
根据缺陷的性质，大致可以分为下列几类
Bad practice 不好的做法
Correctness 可能有不正确
Dodgy code 糟糕的代码
Experimental 实验
Internationalization 国际化
Malicious code vulnerility 恶意的代码漏洞
Multithreaded correctness 多线程问题
Performance 性能问题
FindBugs官方网站上也给出了一些案例：案例点我
排除单个规则
如果是排除一类规则，点击IDE旁边的提示选择排除类型就行
可以针对规则排除单独类中的接触限制，使用注解
@edu.umd.cs.findbugs.annotations.SuppressFBWarnings
要加入依赖 provided代表只在编译时依赖，打包后就没有这个依赖了IDE旁边提示也有这种，不过不会加入以下依赖，需要手动在POM中加入
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>annotations</artifactId>
<version>3.0.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>jsr305</artifactId>
<version>3.0.1</version>
<scope>provided</scope>
</dependency>
2. CheckStyle
代码样式风格检查，专门check代码规范风格的，比如缩进，换行操作，命名大项目往往是有很多人一起完成的，然而每个人都有自己的style，导致整个项目的代码不仅存在不符合语言规范的情况，而且读起来非常困难。因此，这样的项目中都会引入Checkstyle，来规范大家的编码风格，尽量做到统一和合理。所以使用checkStyle检查到问题
官方文档：http://checkstyle.sourceforge.net/checks.html
工具界面
插件
单个文件check
特点
基于源码，无需编译
有maven插件，与IDE插件（eclipse插件，也有idea插件）。idea的一些细节配置
可以自定义规则
CheckStyle底层基于antlr对源码进行处理
可以配置哪些文件不检查
规范配置
配置位置
sun_checks.xml 默认自带sun公司的开发规范，有点严格
google_checks.xml 下载下来好像有点问题，可能与版本有关 查看
华为的规范 很多公司都会用华为的规范改改
自定义的规范 比较了解配置规则的情况下配置技巧
我们在代码写完之后，还要花时间去手动解决Checkstyle提示的问题，这是一个非常无聊和耗时的工作。其实很多问题使用IDE的格式化已经能解决一部分，所以最好能提供一个IDE的formatter配置，整个团队都用这个配置导入IDE，这样用用快捷键就能解决一些问题，非常easy。
3. PMD
与findbug类似找bug用，还有规范，比如说注释不全
特点
有maven插件，与IDE插件（eclipse插件，也有idea插件）
增强代码质量和修改代码的功能
错误分类
可能的bug——空的try/catch/finally/switch块。
无用代码(Dead code)：无用的本地变量，方法参数和私有方法。
空的if/while语句。
过度复杂的表达式——不必要的if语句，本来可以用while循环但是却用了for循环。
可优化的代码：浪费性能的String/StringBuffer的使用。
集合组件
1. IdeaIDE的QAPlug
这个插件是汇集这前面说的3个插件的结果，不用每次都运行3个插件分别排错，1键运行3个同时汇总整合，非常方便，所以其他的不用装了，就用这个就行了！与sonar平台的功能类似！如果公司没有搭建sonarqube平台的话，本地使用这个最佳
插件下载安装
依次下载 QAPlug、QAPlug-Checkstyle、QAPlug-FindBugs、QAPlug-PMD
分类
这个插件会把3个插件的错误分类汇总
Efficiency 效能
Maintainability 可维护性
Reliability 可靠性
Usability 可用性
2. SonarQube
代码质量管理系统相当于QAPlug的工程独立出一个服务器部署，可以配置规则，扫描代码，集成了很多静态扫描工具2015年3月的时候就看到一篇文章介绍这个平台了，那时候还没有太过关注，后来发现这个是个很好的平台
3. Sonarlint
是SonarQube的配套的IDE插件，配置远程服务器的地址,选取要拉去规则的项目，然后本地就可以执行校验了，用的远程的规则这样还是很方便的，规则可以同一在SonarQube维护，不用每个人本地导入，团队的话用这个最适合
Sonarlint安装与拉取列表失败问题解决见
扩充-Lint概念
Sonarlint是一个Lint工具，其实Lint的含义就代表代码静态分析的工具，协助开发的工具，尤其是前端经常使用，比如插件eslint：检查JavaScript错误非常方便
4. JArchitect
多种分析工具的聚合工具是一个商业性的收费的分析工具可以汇聚checkstyle、findbugs、pmd的xml，然后分类总结生成图表不过是收费的，也没有idea插件，不用
代码覆盖率工具
idea自带了代码覆盖率插件还不错跑单元测试的时候以代码覆盖率的方式运行就行了一般逻辑覆盖率60%就差不多了，核心模块80%覆盖标准即可
运行方法
总结
首先要从意识上要遵守规范，风格统一，需要制定一份Java开发规范，我比较倾向于直接使用阿里的Java规范吧，简单实用，也不过分严格其次要选择静态代码工具，没有SonarQube的话用QAPlug是很好的选择，有的话装个Sonarlint插件就可以了代码覆盖率通过idea自带的即可
有些人可能很排斥规范，总感觉条条框框太多，不符合自己的自由风格，但是软件不是开发完上线就结束的过程，而是需要持续迭代维护升级的过程，新人会接手，要有可读性可维护性。项目大了，人多了也是需要规范化才能更好的融合协作，让混乱变得有序一个人的优秀靠的是经验，一个团队的优秀靠的是规范。有了这些规范与工具，就可以大大的提高团队的整体素质与水平，尤其是大厂开发人员，这个是必须有的。
链接：https://www.jianshu.com/p/57b6bdaa1f6b