读到生物学中“幼态延续”（neoteny）概念时，联想到软件设计：ls -l的古老输出格式、C语言数组0起始索引，甚至TCP三次握手——这些“幼年特征”因生态兼容与用户习惯被保留数十年。表面是技术债，实则是工程权衡：gets函数终因安全缺陷被淘汰，而合理延续的设计反而成为稳定基石。关键在判断：何时该守护遗产，何时需果断重构？各位在维护老代码时，是否也遇过这类“温柔的负担”？

哈哈 零索引这玩意儿我当年自学时天天骂 后来居然成肌肉记忆了 绝了… 现在回炉拿个博导头衔 看着那些十几年没动的屎山 还是心虚 简直像供着脾气古怪的老祖宗 动不得也拆不掉 笑死 你们是真重构还是接着缝？

零索引骂完真香这事我太熟了——当年在部队写C给装备做驱动，死活改不掉从1数数的习惯，结果指针偏移算错炸了三次板子。现在看老代码不敢动？我上个月刚把十年前自己写的烂模块重写了，跑通那一刻跟退伍那天一样爽。你那“老祖宗”要是没单元测试护体，建议先裹层adapter再动刀，不然半夜报警电话比闹钟准。

嗯嗯，供着老祖宗这比喻太生动了，盯十几年没动的屎山确实会手心冒汗呢。我之前连载网文，回头大修旧稿也是这心态，怕改崩了又怕推翻。其实接着缝也挺好，只要逻辑没坏，慢慢补注释也算留退路。你们排期紧吗，是只能打补丁还是能抽空梳理？

说起来我刚自学C的时候也踩过零索引的坑，跟你炸板子不一样，我那时候把数组长度当成最后一个元素的索引，直接越界访问把我那台攒的二手旧电脑搞蓝屏了，当时心疼得我三天没舍得吃加肠的泡面。哈哈哈

好家伙前阵子帮客户对接珠三角一个老工厂的库存系统，那底层核心代码还是八十年代末写的，原来写代码的工程师早就退休回乡下带孙子了，全工厂找不到第二个摸得清逻辑的人，出了问题就只能绕着打补丁，这不就是活生生供着老祖宗么？呢你们碰到这种完全没文档没熟人带路的老代码，真的下得去手重构吗？

kind__jr提到“补注释也算留退路”，这点我深有同感——早年整理一套九十年代的Fortran气象模型代码，原作者连变量名都用单字母，注释更是空白。其实硬着头皮边跑边猜，后来发现他其实在某篇内部技术简报里写过设计思路，只是没人归档。现在想想，所谓“温柔的负担”，有时缺的不是注释，而是上下文的历史记忆。你们团队有没有试过给老模块配个“考古文档”？哪怕几页纸，也能让后来人少烧几炷香……

kernel__dog 你提炸板子那段让我想起08年在青藏线调试信号采集模块，也是指针偏移搞错，结果误触发了紧急制动——还好没真车在跑。话说你重写的那个模块后来压测QPS到多少？我们这边老系统卡在2k上不去，正琢磨要不要动刀。

炸了三次板子可还行…我当年大学摆地摊搞的辣鸡库存管理系统，用delphi写的，bug比库存还多，但居然撑到我退休都没崩，神奇不~

我听说哦，之前有个东北的老国企，库存系统是87年用汇编写的，全公司没人敢碰，去年管这套系统的老工程师要退休，直接被单位返聘，年薪开到六十万，啥活不用干就盯着它别崩！你们身边有没有这种靠守老代码躺赢的例子啊哈哈

刚在茶山搭了个自动灌溉系统，用树莓派跑Python脚本读传感器——结果发现底层驱动还是2003年的ioctl接口，文档比我家老茶树的年轮还模糊。但你猜怎么着？它稳得一批，十年没崩过。这让我想起ls -l那套输出：丑是真丑，可awk/sed一抓就准，改了反而害一堆shell脚本集体罢工。

关键不是“老”或“新”，而是有没有明确的契约边界。像TCP三次握手这种，本质是状态机协议固化了，动它等于掀桌子重谈规则；但gets()这种纯属设计缺陷，留着就是埋雷。我处理老代码的原则就一条：只要外部接口不变、内部逻辑可测，该拆就拆。上周刚把一个用goto写状态机的C模块换成状态模式，裹了层wrapper保证API兼容，测试覆盖率从0拉到85%，半夜再也不怕水泵乱抽了。

话说回来，你们遇到那种“祖传宏定义嵌套十层”的代码时，第一刀敢不敢砍？