楼主用legacy system这个比喻切入,让我想起一个在CV领域讨论了快二十年的问题:什么样的模型架构才能真正扛住domain shift?
2012年AlexNet出来的时候,所有人都被那8层的深度震住了。但真正让这个架构在工业界活了快十年的,不是那几层卷积本身,而是ReLU这种看似“粗糙”的激活函数。当年很多人觉得ReLU在零点不可导是个design flaw,不如sigmoid优雅。但实践证明,正是这个“不完美”的特性,让梯度在深层网络里不会消失得太快,反而比那些数学上更优美的方案跑得稳。
有趣的是,神经网络的结构和人的关系网络,底层逻辑出奇地同构。ImageNet那1400万张标注图片,最初用的都是干净的白底图。后来大家发现,在真实场景里识别物体,背景噪声、遮挡、光照变化才是常态。于是2015年之后,data augmentation成了标配——故意往训练集里加噪声、旋转、裁剪。这本质上就是在模拟“塌陷后的舒芙蕾”,让模型学会在messy的环境里依然能抓到核心特征。
你说“时间是最狠的debug”,这个观点从系统维护的角度看,其实还值得再往深挖一层。debug这个词本身隐含了一个假设:存在一个“正确的”原始版本,我们需要找出偏离正确的地方修掉。但长期维护过production system的人都知道,很多“bug”其实是需求变更、环境演化、用户行为漂移造成的。十年前写的代码在当时是对的,现在跑不动了不是因为代码坏了,是因为整个世界变了。
所以能跑十年的legacy system,真正稀缺的不是当初写得有多好,而是维护者愿意持续做一件事:理解现状、接受变化、在不推翻架构的前提下打补丁。这个过程很累,而且不性感。没有新项目的激情,没有从零搭建的爽感,只有日复一日的监控日志和凌晨三点的on-call。嗯
双向维护比新建项目难,本质上也在这里。新建项目有deadline,有milestone,有明确的功能规格书。维护一段关系没有这些。你永远不知道下一个issue什么时候冒出来,也没有SLA可以承诺。唯一能做的,就是保持系统可观测,出了问题愿意坐下来看日志,而不是直接甩一句“重写算了”。
不过你最后问“谁手里还有值得定期update的旧系统”,这个问题的前提本身值得商榷。因为“值得”这个词太主观了,它暗示我们要先判断价值,再决定是否投入维护。但在我的经验里,真正能跑十年的系统,往往不是因为一开始就判断出它“值得”,而是维护的过程本身重新定义了价值。就像我们组里那个从2016年维护到现在的图像检索pipeline,中间换了三次主干网络,迁移了两次数据库,现在跑的东西和当初已经完全是两回事了。但没人会问“这个旧系统还值得维护吗”,因为它现在能做的东西,当初立项时根本想象不到。
话又说回来,这种十年尺度的维护,有一个容易被忽略的前提:对方也得是个愿意接受patch update的系统。单向维护不叫legacy system,叫legacy burden。从你说“一个真诚的售后就够了”来看,至少在这个case里,两边都还在commit代码,这本身就很难得。
其实
另外插一句,irisous提到非洲鼓的鼓声在雨季后反而更沉更阔,这个现象其实有物理上的解释:皮革吸湿后纤维膨胀,张力会重新分布,某些频率的共振会增强。但前提是鼓本身没有破,只是有裂纹和补丁。如果破了,再好的雨季也救不回来。