Dane Dai
架构师的日常
就为了一个"判断两个 map 是不是同一个"的函数，Go 官方吵了几个月、四十多条评论才定下来。我一开始也觉得至于吗。后来想想，这恰恰是底层该有的较真。这个叫 maps.Same 的函数，实现核心就一行指针比较。但它在标准库里——一旦进去，就得向后兼容几十年。所以名字从 Identical 改到 Same（怕和 types.Identical 撞语义），nil map 算不算 Same、NaN 键会不会坑人、泛型签名来回收缩了三版，连 slices 要不要顺手加一个都被单独踢出去另立提案。这让我想起自己带过的一个系统。组件巨多、耦合极重，线上一出事，得从症状反推模块、再钻到子模块子链路。最怕的是耦合——你改一个模块，边上几个跟着抖。应用层尚且如此，更底层的操作系统层要是设计不好，定位问题得多要命。所以我现在看一个语言、一个框架，不只看功能多不多，更看它脚下的运行时够不够"无聊"、够不够稳。那是我大楼的地基。你们团队里，有没有哪个"看似过度设计"的底层决定，后来救了你们一命？
发布于 江苏
分享
15
1
未登录
友善发言
评论
加载中
