敏感词算法坏味道修复经验分享 Sonarqube代码质量修复的过程是一个思考历练的过程 权衡代码可读性可维护性与性能的平衡点

一般的坏味道都比较好处理，像变量名大小写、立即返回结果、去掉多余的boolean判断等等，常规类型的坏味道清理起来很快，按sonarqube的提示，很快就可以搞定。有一些，坏味道，可能就不用处理，这个看团队怎么排除一些sonarqube的不合理的地方。通过运用设计模式啊，运算啊，都很可能产生“花瓶”代码，像状态机，就产生了很多空的占位方法，sonarqube会报重复率，这个时候，可以忽略掉，不予以处理。

今天最虐心的是敏感词算法坏味道，这个算法拥有强大的复杂度，while,for,if嵌套层次多，被sonarqube要求降低复杂度。

困境

这么精致的代码，改错一行，估计就凉凉了。无从下手，在于，代码本身的可读性就差，代码都在一个方法里，远超一屏代码，读懂就比较费劲。算法运用了不少全局性质的哨兵变量。

•  
•  
•  
•  
•  
•  
•  
•  
•  

inTag;i;start;count;isBack;offset;target;branch;chars;

理不清，还乱！

顿悟

放空许久后，突然有点灵感。sonarqube要求降低方法的复杂度，无非要求别把代码堆在一个方法里，将方法合理的拆成多个，把单个方法的while,for，if层级降低。全局性质的变量，要在多个方法间传递，那就打包到一个context中，然后就可以任性的降低sonarqube所谓的复杂度了。

•  
•  
•  
•  
•  
•  
•  
•  
•  
•  
•  
•  
•  
•  
•  

@Datapublic class ContextBean {  private int inTag;  private int i;  private int start;  private int count;  private boolean isBack;  private int offset;  private String target;  private SmartForest<String[]> branch;  private char[] chars;  public void plusI(){    i++;  }}

顺势而为

有了context，接下来就是拆分层级了。先抽出来一个dealChars，再从dealChars中抽出来一个dealChar，再从dealChar中抽出来一个judageChar，单个方法的复杂度也达到sonarqube要求了。代码可读性好像也提升了。算法并来就不好读~^_^

收尾

经过今天敏感词算法的坏味道洗礼，总结出一个对于复杂度高的算法代码的坏味道修复经验，建立一个 context,将变量打包进去，再将算法拆成多个方法，降低单个方法复杂度。