我在Java开发工作中的一些心得体会，不断更新中

 

2020/10/10

十一假期前，进行了一次代码评审，发现我代码中存在的很多问题。确实令我汗颜，在此记录一下。

1、排序不能使用$符号，跟产品事先定义好有几个排序，然后把这些排序在mapper.xml中写固定。通过传一个flag来判断使用哪个排序。

2.不能使用 where 1=1，太low了，使用<where>标签。

3.参数校验不能写在controller层，而是写在service层，因为service层不光可以用在控制层，也可以用在别的service中调用。在service层做校验，只需要做一遍就可以了。

 

11/12

今天好险，我看同事的代码的时候，觉得明显有问题，于是我想给他指出这个问题，但我没直接说你的代码有问题，而是说你的代码我有些看不懂，请你给我讲讲。结果人家一讲，我才发现写的其实没问题，是我没认真看！差点丢人了。。

以后都得这样，不能武断的认为别人的代码有问题，很可能是自己没看好。

 

2019/8/22

思维缜密，思路清晰，寥寥八字，但真的做到很不容易，昨天业务反应的一个问题，我简单一思考，就把原因往前端那边想，而对自己这边可能出现的原因，却怎么也想不起来，这就说明我思维还不够缜密，我的leader，稍加思索， 就能一语中的，指出问题所在，真的好惭愧！

问题大概如下：页面上一个查询功能，一个导出EXcel个功能，用户输入了一堆查询条件，查询好使，但导出就立刻报错，查询和导出 组装查询提交件的代码 是通用的一个，我当时就想到这是前端在传参的时候没传对。但却忽略了一个问题，查询和导出有个不同点，导出需要往一张record表里写入一条数据，这个表里有个字段 叫输入参数，这个字段的length是有限的，如果用户只是简单的查询，完全能胜任，但用户搞了一个很长的查询条件，结果写入数据库记录的时候，立马就报错了。

2019/8/20

非空校验：如果入参是一个List<T>，那么需要做如下四种非空检验：

1.list本身是null，

2.list的size是0     这两个统一使用 CollectionUtils.isNotEmpty()方法

3.list中的元素T是null

4如果需要使用list中的元素T的属性去调用方法，还需对T的get出来的属性值就行非空校验

5.根据阿里编程规范，字符串equal时，把字符串常量和你认为肯定不会为空的参数放到左边，因为一个null调用equal()方法，百分百会报错，但是把null放置到equal()方法内，就不会报错。

 

昨晚搞到凌晨1点，问题是这样的，一个导出Excel功能，我在我本地测试是好使的。我本地连测试环境的数据库，进行测试，也是好使的。但是代码部署到测试环境后，就不好使了，什么也导不出来……11点12点，我找了两个小时，想找出到底 我本地和测试环境，哪里不一样，但始终没找到、

最后，还是我经验丰富的leader，他看了下我的代码，几分钟就定位出了不同点！原因如下：代码是一样的，连的数据库也是一样的，但我在程序中调用了一个dubbo接口，这个外部接口，在我本地，和在测试环境，访问的IP不是一个环境，所以拿到的dubbo远程接口数据也就不一样，所以在我本地好使，但部署到测试环境，就嗝屁了！！

俗话说，吃一堑长一智，以后再遇到这种“找不同”类型的bug，我一定要思维更加缜密，更加冷静分析。

 

经过最近两天的实践，前些天一直困扰我的idea编辑代码时，内存飙升 卡死的问题，罪魁祸首就是阿里巴巴出的P3C插件的实时检测，右键，把实时检测关掉后，一切的卡顿都烟消云散！哈哈，没想到阿里巴巴这么大牛，也是一个坑爹货，P3C插件没有给我们用户任何关于实时检测占内存的提示！

 

2019/8/15

bean中的属性，布尔类型记得一定要用包装类大写的B：Boolean，而不要用小写的关键字boolean，还有命名布尔类型值的时候，尽量不要以is开头，不管是lombok，还是属性复制，还是序列化，这其中都有大坑，哈哈！

 

修改bean属性的时候，一定要有修改后building的意识，因为我不能知道这个被修改的bean都在哪用到了，修改后本地不building，直接提交的话，造成报错，到时就很不好了、

 

2019/8/14

今晚给一个新员工解决git无法拉代码的问题，什么都配置好了，但就是拉不下来，耗了一些时间，最后重启电脑才好了，总计下经验：还是重启治百病，哈哈！

如果项目本来用着好好的，更新过git以后，突然就无法启动，那十之八九肯定是上个提交人员，提交的代码引出的问题，这时，话不多说，直接看Git提交记录，把肇事者拎出来

 

Idea的常用快捷键经常会被别的一些软件所占用，我的态度就是绝不容忍，一定要把占用热键的幕后黑手揪出来，然后改掉。目前，我个人体会占用热键最多的就是，有道词典和搜狗输入法这两个渣渣，但都可以通过改他们的设置，把热键再改回来

 

最上方的import导包行上面，要注意一点，随着多次的开发，import会有一些不用的置灰的包，每次提交代码前，需要检查下这些import，把无用的去掉后再提交。Idea有一个自动导包（Auto Import）功能很好使，会把没用的包自动删除掉，建议开发团队一块儿用，如果只有一两个人用，会出现每次commit代码时，会多出来好多different

 

开发当中，一遇到问题，不要马上问别人，因为你问别人一次，就是打扰别人一次，就是打断别人的思路一次，一天多次打断一个程序员的思路，无异于谋财害命！我觉得，在不卡住自己开发进度的情况下，可以多积攒几个问题，一块问。

 

 时不时的会在开发中遇到NullPointerException异常，主要实在dev和test环境，这两个环境的数据往往是不完整的，是有缺陷的。如何在开发中尽量避免空指针异常呢？

非空检验宁滥勿缺，加非空检验主要有以下几个注意事项：

调用外部的接口，比如通过dubbo调用远程服务，得到一个返回值，就一定要检验这个返回值。List<T> 集合类型的返回值，校验集合本身不为空，并且集合的size大于0。通常项目中有封装好的方法，如：CollectionUtils.isEmpty();取反

遍历取出List中的元素，通过get方法获得元素field时，如果要调用该field，一定要加非空校验。要做最坏的假想，认为所有数据都有可能出现空值的情况。

平时在开发中，要有加非空检验，增加程序健壮性的意识，不要等到被测试人员测出了空指针，再去加。

 

编码中需要的七个意识：

多写注释的意识，为己为人，为了以后能快速看得懂代码，多写注释，特别是一些复杂的功能，一定要多写注释

多打log的意识，多打log，最大的好处就是方便在生产环境排错

 

非空校验的意识 记得用Optional

分拆代码的意识 长方法，分拆成若干个小方法，根据阿里的编程规范，每个方法最多80行

提高复用的意识 一些与业务无关的的util类方法，写到统一的一个util类中

使用新语法糖的意识 Optional和双冒号:: 在后续的开发中，一定要用起来

代码简洁的意识 尽可能的多使用兰慕妲lambda表达式

 

调用dubbo服务时，调用的入参size要可控，不能一次一调，也不能一次大批量的调用。