目录

背景

技巧说明

探针级--差异比较

入门级--分段扎针

高级别--赢在准备

小结

背景

工作中维护Java项目，框架或者依赖jar包升级司空见惯。作为RD，我希望能够平滑兼容，不过有时兼容也是一项浩大的工程，所以选择不兼容，例如SpringBoot 1.x迁移到SpringBoot2.x。
在这种情况下，项目难免出现原来正常，升级后异常的情况。这种问题，我称之为佛性问题。过去也解决过几次这种现象，对其中使用到的技巧做一下总结。

技巧说明

探针级--差异比较

我有许多问题都通过该方法解决。比较关键对象, 变更前和变更后的差异，毕竟这些差异很有可能是罪魁祸首。针对异常现场相关的对象做差异比对, 比如Web项目中的FilterChain中Filter的类型、顺序和运行时变量。如果差异有影响, 开始DEBUG是必须的。
想补充的是。如果差异没有影响, 也需要DEBUG确认, 并记录下来因为可能影响是间接的。此外, 运行时变量由于太多, 无法逐一比较, 差异很容易被忽略。这里建议关注对代码流程有影响的关键变量。比如原本默认为FALSE,现在默认为TRUE, 这种被发现时想打人。还有如果本地运行不OK, 发布到测试服务器上试试。自己电脑不行, 用别人电脑试试。Windows不行, Linux上试试。

入门级--分段扎针

如果一针不见血, 那就把整体拆分多块, 每块扎一次。把待更新的整体, 拆解为多个部分, 逐步升级, 仅在当前PART升级无问题之后, 再进入下一个。这样将问题范围缩小在具体的一小块，避免迷失在代码的汪洋大海中。这种方案比较稳妥, 可以准确地反馈升级进度, 提高升级的信心。此外, 如果剩余内容真的有问题, 已验证的内容可以先上, 作为升级失败的折中方案。

高级别--赢在准备

首选,了解升级的必要性。 升级是别人感觉简单认为就是改下版本号, 自己觉得压力山大, 但是又无法把山描绘出来的事情。据我了解, 往往做好了功劳是别人的, 出问题锅是自己的。其次,比正常业务开发更谨慎地排期。毕竟, 风险是未知的, 出于负责的考虑, 你需要充裕的时间。尽可能用别人能理解的语言, 阐述风险, 并尽可能寻求外部支持, 参与的人越多压力就越小。想象一下,遇到佛系问题, 可能忙活1天也没有进展, 你的进度在哪里？最后,开始前尽可能获取组件changelist和releaslog并仔细阅读, 结合项目做到心中有数。比如spring session组件在1.x版本时是一个独立组件, 到了2.x拆分为了spring-session-core和spring-session-data-x两个组件, 这样在开始就能注意到影响。话说回来, 了解到什么程度是OK的, 我只能说自己认真读过, 结合项目分析过, 在小本本上记上几个注意事项就OK了。

小结

这里讨论排查问题的三个技巧，实际工作中需要综合运用。在没有头绪时, 我也曾一度怀疑项目是"薛定谔的项目"。但仍然需要坚信, 是自己的错, 而不是电脑的锅。