互联网业务的创新性直观体现在大多产品只有两三年的生命、之后就有新产品替代，一些活下来的也基本隔两年都会改版升级品牌。但还有一些产品、典型例子比如支付宝电脑版网站的 “安全中心”、“收银台”、“安全控件”，由于一些客观原因（2012年的 all in 无线）长久没有重大升级，但因为也是业务主链路、非常重要而不能下线，因此就这样“放”了 10 年在那里。当然平均每隔半年还是会有一些小功能需求的。
作为技术人员、能接触维护这样的产品、那是相当幸运又不幸的~ 要知道这些产品代码不少是现在已经脱离一线的大老板们当年的作品、这是瞻仰和学习的机会呀，再者万一你写的比当年老板好、心里还会美滋滋一下是不是~ 开心之余、遇到问题就感到特别不幸了，以下是一些让人痛苦的点…
- 老技术的文档基本是找不到的、没人维护了。
- 想解 bug？乖乖先把代码一行行看懂（最好先阿弥陀佛、不要遇到压缩版代码）。
- 千辛万苦改好代码，却发现“构建、发布”功能跑不起来了、甚至已经下线了…
- 万一真都改好能发了~ 但这是重要的 A 类系统、被其他上百个系统引用，灰度后系统回归的工作量让你头大，遇到问题还得等两周一次的发布窗口！
- 上线就一定没问题了？到用户这边又有坑了，升级出问题了、监控数据异常暴增、没法回滚了（风险要兜起来 解决掉）。
这些老产品随着运行环境和业务变化、产品漏洞会越来越多、时不时来个故障，结果是导致产品链路上各方都在填坑、都很蒙圈。产品像电影一样老成了经典，在背后技术上、却也“难看”到了极点~ 当然技术维护同学一般是很希望“老树开新花”、好借此有个机会来个技术彻底大重构。但运营或产品经理提的零碎小需求根本体现不了多少价值、甚至连局部的小重构都难以借此开展。
再具体到“拿结果”上，对比一下新老产品的技术维护、也有一些有趣的点：
- 老产品：有时候两年能换四五个人轮番支持，日常主要也是问题修复和小需求迭代，拿不到明显的结果。
- 新产品：虽然是从头开始、但不是从 0 开始，能基于已有技术基础、各种经验，技术实现出来的难度并非很大、很容易有不错的结果。至于业务价值、有产品经理帮你论证，业务结果、有数据监控帮你说明，作为技术人员也不用为产品的生存状况负责。
所以，有新同学问、入职两年了 一直负责老业务，如何成长？？在老业务中、各个角色拿到的结果是什么？对于更新快速的 IT 互联网技术来说，可能对老产品背后老旧技术的学习或解决问题的实际意义不大、甚至确实是浪费时间，从老业务里获得的进步和成果都很有限、这确实是事实。不过也有句话说的好：不了解过去也就不能理解现在，就没有多少希望掌握未来。而老业务老产品、多是一个公司安身立命的支柱性产品，公司所有后续的创新也必然是在这些基础之上。所以对于没接触过老业务的你、是可以借此机会在维护技术的同时也能把重心放在对老产品本身的理解学习上。