SonarQube
SonarQube是用来检测代码质量的，但类似工具的推广常常遇到阻碍。
成型项目或僵尸项目可以理解，项目优化需要投入的人力成本和时间成本太大，而且最主要的是无法保证改动过程中不引入新的bug。那么大家会想，在项目立项初期配合使用，这应该没什么问题了吧？奈何理由这东西，只要想找，总是有的。毕竟大家都喜欢待在舒适区，不喜欢折腾。试想刚提交完代码没多久，邮件就提醒你需要优化，打开一看，原来又是for循环太多、嵌套太多、重复代码太多或者方法行数太多。why？我实现功能不就行了吗？时间这么紧迫，怎么有时间修改这种问题呢？连这些小问题都抓住不放？呵呵，以后有时间一定改。
我起初也这么想的，虽然知道好的习惯养成很重要，但还是避免不了有所抵触。不过好在上头规定相关类型bug必须清零，坚持的时间一长，收获还是蛮大，最直接的体现就是代码易读性加强了。这个时候我突然就想起了设计模式。
设计模式
自大二接触Java以来，就知道IT界有一种无上功法叫设计模式，然后就一直想着哪天能融会贯通，挥手间，就是一片锦绣代码。
可是这些年过去，设计模式给我的感觉就是遥不可及，仿佛它只存在于面试题中，而且奇怪的是大家闲时谈论技术也很少涉及，why? 首先自我反思，那是自身水平不行，get不到核心，但我相信这不是全部原因。
我认为设计模式的出现是为了更好的写好代码，它只是手段，不是目的。奈何这系列手段太高明，完全不是初级菜鸟的菜。初级菜鸟没掌握，那大神级别的平常为什么也不怎么谈论设计模式呢？我想，可能是因为不同层级的人，如果用设计模式里面的逼格名词谈论，根本就无法沟通，因为我们平常是这么讨论的：
- 这个类负责创建这个对象，对。然后这边包装一下，对的。
- 嗯，你这个类就是针对他的Interface做的一个Adapter，是的。
- 你这个只创建一次，提高性能。哦，对，没错，但这样更好，balabala...
所以设计模式大部分情况下只是给大家提供了一条快速提升逼格的途径，要是没有时间上的积累，就算把所有设计模式的名字都背下来，可能还是不太会用 0.0
SonarQube & 设计模式
那么怎么才能优雅的掌握设计模式呐，想来想去，我的方法是先了解它的各种使用，知道它的存在，然后在具体的使用层面上只是借鉴它。如果你对代码有高要求，在任何情况下，都会努力去提高代码的可读性，都会去控制你的代码量、减少嵌套与循环、减少各种潜在风险时，我想时间长了，无师自通，自有一番风景。
