小记：成品代码改造的隐患

背景：

近期进行过一次代码改造，要求把原来代码中与当前业务不符的命名进行修改，统一框架，修改字段类型。

内心戏：

想着这种改造不可控性太高，但又一时找不出一些例子用以说明，便委曲求全答应了，小心翼翼的改完了，最后测试时果然发现还是有一些难以发现的问题。还是不改为好。

问题：

1. 名词的变更，如*Group*变更为*App*。虽然可以通过idea重构功能（Shift+F6）和全局替换（Ctrl+Shift+R)来进行替换，但是Map中的Key可能含义不同，导致本来不该替换的被替换了。比如，你用到的中间件也有一个Group的概念，与我们系统含义不同，此时就有可能过多替换导致错误。
2. 类型的变更，如id原来是String，变更为Long。

• 其一，是关联的外键XXId也要替换，id也很难识别替换。我就几乎没改。
• 二是，容易忽视的也是Map，比如有个List，通过Stream转换为Map，key的类型前后是不同的，用Long无法取出String的值，且有时候没有明细的编译错误，不容易识别。
• 三是，mongodb存储数据时类型是动态可变的，与Map上述情况类似，存进去没问题，可是查不出来，没有明显的编译错误。

3. 以上也告诉我们，为什么代码规约里不建议使用raw类型，不可控啊！
4. 自增字段容易忽视导致错误。

---

想起来再补充吧~
5. BeanUtils.copyProperties(request, target); 变更类型后，复制失败，编译不报错，很难发现。