那些年优化-同事的 shit 代码

         随着业务的深入，已经不满足于日常按部就班的处理每个迭代的需求，可以腾出一些时间来处理那些狗皮膏药的代码， 这类代码的通病：

1. 无任何注释，其实还好，很多时候是直接从别的业务搬过来且连其他业务的注释都一字不改，更有甚者，连log 日志都不改，导致排查线上问题时，阿里云上充斥着各种牛头不对马嘴的日志

2. 大量的判断语句， 一层连着一层， 有些还放在 foreach 循环中

3.  各种集合类对象先判断null 再去判断 count 是否大于0 ，重复操作

前面的这些都是语法类， 调整起来并怎么花费时间， 有些业务类的处理逻辑，洋洋洒洒好几十行代码，各种处理， 非常唬人，待稍微了解其需求后，便觉得简直是离谱， 离谱到家了,  如下： 宿舍管理人员变更时逻辑：

 

 接着往下看，离谱的写法，如下所示：

 可以看到，这些在代码冗余上面，简直是各显神通， 代码想表达的意思无非就是，多的人要加入表中， 少的人要从表里面剔除掉，硬是搞了两个for 循环 +if 判断 ，循环次数复杂度看的人恼火 ,.如此类代码统统可以一并优化，

 

这代码也是没谁， 接着进行优化， 可以看到，代码 大量的if ，else 判断，以及foreach 循环，都是为了获取两个集合，一个是多了哪些人，一个是减少了哪些人，不仅有如此的写法，同样还有使用 双层的 foreach 循环 且夹杂着 if 的判断来 获取新增的 和减少的人，代码如下

， 简单的处理，就是两个集合取差集而已，可以直接用except 操作， 拿到两个集合（增/删），然后在分别对像个集合中的数据进行相应的逻辑处理，

优化后代码如下：

 可以看到，优化前大量的花式判断，直接精简到两行except代码 解决，而且可读性高，易于维护