这是一个创建于 641 天前的主题，其中的信息可能已经有所发展或是发生改变。
每次升级依赖都要小心翼翼，一不小心就出现不兼容
- jetcd
- grpc-java
- guava
 | 1 weijancc 2024-01-11 16:14:17 +08:00  1 Google 的 gson 会将 json 中的数值解析成 double, 也是蛮坑的 |
 | 2 kingmo888 2024-01-11 16:15:48 +08:00 所以非升不可嘛？ |
| 4 kingmo888 2024-01-11 16:49:00 +08:00 @Goooooos 想起了前年 12 月吧，生产环境上 py311 ，赶上内存泄漏，日常 1G 内存，1 周跑到 32G.哈哈 |
 | 5 nothingistrue 2024-01-11 17:26:29 +08:00 如果你紧跟 Java 最新版本，那么可能会更容易碰见不兼容。当你依赖的基础组件是敏捷开发的，而你自己有不是敏捷开发，那被升级兼容性问题坑是早晚的事。 你最好也是跟着一起敏捷开发这要求近乎 100%自动单元测试，虽然不能避免兼容性问题，但是能第一时间爆出问题让你去解决。 |
 | 6 gongxuanzhang 2024-01-11 19:24:40 +08:00 一切兼容问题都可以用测试解决 |
 | 7 kuanat 2024-01-11 20:27:10 +08:00 6 很多时候不兼容的改动都是“无意识”的，开发者以为修改是向后兼容的，但实际上不是。这种错误我犯过不知道多少次了…… 关于向后兼容这个话题，我推荐两个讲座，都有视频和讲义： - How to design a Linux kernel interface, https://archive.fosdem.org/2016/schedule/event/design_linux_kernel_api/ - Detecting incompatible changes, https://sourcegraph.com/blog/go/gophercon-2019-detecting-incompatible-api-changes 简单做个总结。Linux kernel-userspace API 早期的失误造成的影响已经持续了几十年，很多还将继续影响下去。这些失误的来源多数是设计者想象不到下游开发者会以什么样的方式去使用这些 API 。 规避的措施就是自动化测试，而自动化测试需要对 specification 进行规范化。实际上推动了开发流程的改变，即先公开规范和 API 设计，提供实例代码，接受反馈并修改设计方案，最后再实现功能和测试。而不是过去的先做实现，然后公开 API 接口的模式。 （这个事情做到极致大概类似于 amazon ，先开发布会，然后再开发） 第二个讲座虽然是 Golang 的，但指导意义很大。核心是如何从技术上自动判定某个改动是否会影响兼容性，进而对如何编写“面向未来可兼容扩展”的 API 接口提供理论支持。Golang 的开发团队为 Go1 的兼容性做了很大的努力，有非常多的案例经验可以参考借鉴。 |
 | 8 Knife42 2024-01-12 21:34:44 +08:00 @kuanat 大佬好，冒昧打扰了。v 站好像没有私信，我就直接在这说了。我是刚才看到你的回答 https://v2ex.com/t/1007645#r_14194875 感觉学到了很多，好奇之下看了你别的回答，意外发现对我来说都很有启发。想了解下大佬你有别的社交账号吗？或者 github id 是什么？想关注 |
| 9 kuanat 2024-01-13 01:33:03 +08:00 1 |
Select Language