前言

最近IntelliJ又由于自己的骚操作给弄崩溃了，导致之前弄的一大波配置又找不到了，十分蛋疼的又要开始重头开始弄环境。很多之前精心搞过的配置又都记不住了，为了防止以后出现这种情况，这里就把我日常用的配置和注意点记一下，免得以后又要重新摸索。尽量持续更新。

安装

安装这块没啥好说的，不过要注意的是，虽然 IntelliJ 有 Community 版，但是毕竟还是少了一些东西的，比如对JavaScript的支持、一些静态检查的支持、Spring框架的整体支持等等。因此还是不要太委屈自己了，安装个正式版然后激活下好了（罪过罪过，实在是正版太贵了）。

配置

修改文件模板

合作写代码的时候，一般都要求在自己创建的文件头加上一些创建者的信息，用以方便交流。

方法是找到下面的路径：File > Settings > Editor > File and Code Templates > Includes > File Header，并修改文件模板：

1
2
3
4

/**
 * @author ${USER}
 * @date ${DATE}
 */

当然，@date 并不是标准的javadoc注解，不过也无妨了。

修改编辑器样式

问题痛点

最近维护了一段时间的组件包，在向同事进行推广的时候，经常会听到身边会有类似的抱怨：

• 我靠，为啥你们的包带了一大堆乱七八糟的依赖，把我的classpath都给污染的不像个样子了。
• 我靠，你们这个包依赖的xx包的版本跟我们自己依赖的xx包的版本不一样啊，会不会出锅？
• 我靠，我这个代码编译的时候没问题啊，为啥一用你们的组件就报一堆的NoSuchMethodError啊。

有时候自己写代码的时候也会遇到一些容易被忽略的问题：

• 哎，我看人家引这个包的时候都会exclude一些依赖，我要不要也学着exclude一下呢？不管了，先一起粘过来试试看。
• 哎，怎么我的classpath里的某个包有三四个不同的版本啊，跑的时候到底用的是哪个版本啊？不管了，反正差不多，先跑跑看。
• 哎，我怎么直接就可以用这个类了，这个类是哪个包引的？不管了，反正IDE爸爸提示我能用，先用着再说。

大多数情况下，忽略这些问题一般也不会造成太大的影响，就算出了线上bug，一般也能很快定位问题、强制指定一下依赖的版本号就好。但是不得不说，依赖调解是普通java开发人员经常会遇到的问题，无谓的浪费了我们大量的时间和精力。尤其是当项目越来越大，用到的组件越来越多时，内耗就更加明显。

业内方案

大概研究了一下，目前对于本地依赖调解也没有什么很好的银弹。绝大多数情况下，我们都是在流程、文档上来进行把控。而从技术角度说，或许有如下几种方案供我们选择。

代码内嵌

这个方法很老土，但是也好用，就是把依赖到的包以源代码的形式放在自己项目的包中，而不是以依赖的形式引入。这样的好处就是组件一定可以依赖到自己想要引入的包，不会收到业务方引入的包的影响。不过坏处就是缺少了灵活性，业务方无法修改组件包的任何依赖。

前言

前两天我们组负责的一个组件发生了一个与jar包版本号有关的线上bug，最近没啥事情，就顺便分析了一下。

其实是个非常无脑的小bug：commons-lang3包中有一堆@since 3.5的新增方法，我们的组件依赖了3.5版本以上的一个包；业务方依赖了我们的这个组件，同时也直接依赖了一个3.5版本以下的包。在gradle打包的时候，由于老版本的是直接依赖，新版本的是间接依赖，直接依赖优先级高于间接依赖，因此最终采用的是老版本的包。这就导致在运行期调用新方法的时候会报NoSuchMethod的错。

虽然问题很简单，但毕竟也是一个影响了GMV的线上事故（可怕），值得吸取一波教训。

方案

一般来说，在比较大的项目里，依赖冲突这种事情几乎是无法避免的。一般来说，这种问题的解决方法大多是下面几种：

1. 对于业务方来说，写代码的时候小心一点，遇到不同依赖的时候，有意识的检查一下依赖树，尽量使用较新的包，并且代码上线之前需要在测试环境充分测试。
2. 对于组件开发方来说，在写接入文档的时候要同时指明依赖的包的最低版本号，清楚地告诉接入方最低的依赖，然后再由接入方手动指定。
3. 采用容器技术，比如OSGI、Jigsaw、Karaf这些容器，对jar包再进行一层权限控制。这是一种十分重量级的方法，一般项目得上了一定的规模才会使用。
4. 采用ClassLoader隔离技术，各个包都使用自己的classLoader，互相不影响。这种方法其实很像是容器技术的阉割版，逻辑上很像容器，对jar包再做一层隔离控制。不过这种方式一般不是很优雅，有点像hack，因此目前看起来没什么像样的完整解决方案。稍微像样点的大概就是阿里最近搞的Sofa ark，功能挺强大，但是用起来也比较复杂，对jar包的侵入性也很强。

各个方法其实都不是很方便，那就换一个思路，既然避免问题比较困难，那就尽量早点暴露问题。编译错误或者启动错误肯定会比运行时不知道啥时候报错更让人放心。因此根据fail fast原则，我们应当保证在不增加沟通成本的情况下，快速暴露问题。

分析

既然很多依赖冲突问题在编译、打包时都不会报错，那就只能尽量在启动时报错了。因此对于一个稳定的组件来说，做一个运行时的启动检查也就有一定的合理性了。

前言

这个礼拜似乎是写了一礼拜的业务代码，没遇到什么太恶心的坑，就是理解业务逻辑费了点功夫。下个礼拜似乎又要开始撸组件撸网页了，现在想想感觉还是写写业务比较舒服，没事可以怼怼产品，给前端找找bug，写完还可以慢慢测；撸组件就比较无聊了，容易出大锅，而且还得求着人家用，用出问题还会被怼。。。不过好处大概就是以后跳槽面试的时候不容易被问死吧。。。

知识&技巧

常用@see和@link注释

写代码的时候经常会遇到一些需要枚举的类型，比如“活动类型”、“数据来源”这类的。但是一般来讲我们不会直接用enum类型，因为这些数据一般都是以整数的形式存储在数据表里面，因此用整型去存储、转移会更加方便。所以一般我们都是直接声明成一个整型，然后用另外一个类去存储这个类型的值，比如:

1
2

//需要引用的地方
int xxxType;

1
2
3
4
5
6

//该类型的值
public interface XxxType {
    int type1 = 1;
    int type2 = 2;
    int type3 = 3;
}

这样搞没啥问题，但是比较讨厌的就是，当另外一个人看到xxxType这个字段时，他可不知道这玩意的值是XxxType去记录的，他甚至有可能去用YyyType的类型去给xxxType赋值。这就说不清楚了。

因此一个比较简单的方法就是把注释写清楚了，而相比普通的注释，java的文档注释就比较好用了。这里面有一个@see的注释，非常适合这种场景：

1
2
3
4

/**
* @see the.package.of.XxxType
*/
int xxxType;

也可以使用{@link}注释，达到类似的效果:

1
2
3
4

/**
* {@link the.package.of.XxxType}
*/
int xxxType;

这样无论谁在给这个字段赋值时，都非常清楚的知道该赋什么值了。这一点jdk做的就非常好，要向他学习。。。

前言

好快啊，又是一周的轮回，本来打算把本周遇到的问题展开一个一个总结的，但是奈何踩的坑是在有点多，展开来根本没时间搞，索性就搞了这个类似周报的东西。希望从这一周开始，每一周都能坚持下来喽。

由于跟给老大看的周报不同，这个是给俺自己看的，所以成果啥的就不表了，主要表一表自己写的bug跟领悟。就记一些大实话吧，”写者有罪，闻者足戒“。

知识&技巧

while循环的控制逻辑写在循环体内

这句话是同事跟我讲的，领会了下他的意思，大概是，下面的写法二要比写法一好:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

//Method1
while (!shouldBreak1() && !shouldBreak2()) {
    //Do sth
}

//Method1
while (true) {
    if (shouldBreak1()) {
        break;
    }
    if (shouldBreak2()) {
        break;
    }
    //Do sth
}

方法一看似简单清晰，一行代码就完成了控制逻辑，但是这样其实有弊端:

1. 调试麻烦，如果条件越来越多，容易混淆出错的到底是哪一行
2. 打日志不方便，这很显然
3. 逻辑一致性较差，有的控制逻辑可以写在开头，可有的控制逻辑就无法写在开头了，这时候不如都直接写在代码体里，保证一致性。

当然，复杂逻辑适合方法二这么搞，但是辩证的看，如果逻辑比较简单，用方法一也无可厚非嘛。

不要对数据表的记录进行物理删除