技术的发展速度超过了程序员的学习速度。

用几个例子支撑该观点。

例如，在过去一段时间里，高并发的后台服务离不开对数据库做分库分表。原因很简单：单个数据库节点难以承受高 QPS。

分库分表时，后端程序员需制定合适的哈希策略，防止数据倾斜；实现分布式事务框架，确保跨物理库的写操作具备原子性；制定平滑迁移策略，以确保扩容数据库节点时数据迁移不影响在线业务。

分库分表是不是听起来就很复杂？

总之，后端程序员需要具备一定的工程经验，才能正确实施分库分表。

结果，分布式数据库直接消除了分库分表的需求，自动解决上述问题。

这也带来了一个尴尬的问题：当一个擅长分库分表的程序员带着经验加入一个使用了分布式数据库的新项目时，他会发现这个经验难以发挥作用。

究其原因，是技术的迭代速度超过了程序员的学习速度。程序员容易学着学着发现，所学的技术已经过时了。

再例如，在过去一段时间里，写网页意味着用 php（或其他模版方案） + jquery。但现在，nodejs + wepback 给前端开发的工作模式带来了巨大的改变。现在，开发前端意味着学习：webpack / rollup、typescript、vue / react、 scss 等等。当前端涉及 ssr 或 bff 等更高阶的架构时，开发还需要学习 nodejs 以及后台知识。

这也带来一个尴尬的问题：当一个熟悉过去模式的前端开发者加入到新的团队时，他很可能无法适应。

这不是一个架空的问题，而是真实发生的问题。一些 5 年以上的老项目至今都在使用模版渲染 + jquery 构建前端。而维护这些老项目的程序员多半是主职后端，半兼职前端。他们熟悉了模版 + jquery 的模式。他们学习新的前端开发模式是有一定成本的：原来只是做一个 html 静态资源渲染 + 后台转发，现在要学一大堆前端编译构建 + 独立部署。

这也是因为技术的发展速度超过了程序员的学习速度。程序员可能学着学着，发现原来的知识体系已经不适用了。

当下，技术仍在持续发展。最近 AI 辅助编程（Copilot），甚至 AI 自动编程（HuggingGPT 项目）取得了阶段性成果，且仍在持续发展。在三五年以后，程序员所需要的技能仍会改变。

技术是一直在变化进步的，且进步的速度很快，超过了程序员学习的速度。有时候，程序员会拘泥于具体的工程实现技术栈，「吹捧」一两项技术多么强大。结果是，这些使用具体技术栈的经验，会因技术发展而被慢慢淘汰。

比如，我记得前几年后端面试流行考「百万并发架构」：Kafka + Redis + MySQL 分库分表，还喜欢考有关中间件的底层原理。但随着云技术越来越成熟，现在弹性伸缩 + 缓存 + 分布式数据库的架构已经能应对很多并发场景。一些中间件的设计也从之前多个有状态的计算节点架构，演变成了更清晰的存算分离架构。

扯了这么多，我不是想说明程序员不该学习技术，也不是想说明新的技术就一定比老的技术好，而是想说明：在考虑职业生涯发展时，程序员不能只拘泥于某几个具体的技术栈。因为技术一直在发展，若程序员拘泥于某几个技术栈，那他容易被淘汰。

在考虑职业生涯规划，以应对 35 岁危机时，程序员应该意识到：自己必须锻炼特定技术栈以外的能力。

比如，程序员可以锻炼需求理解、系统设计的能力。随着时代发展，虽然某些技术栈会改变，甚至被淘汰，但是理解需求并应用技术解决需求的能力，是持续被程序员需要的。

比如，程序员可以锻炼项目管理的能力。对于一些中大型项目，项目管理的能力和技术能力同样重要。一些糟糕的存量系统，正是因人力不匹配、优先级不尽合理、排期不合理导致的。程序员在平日里吐槽项目决策时，可以顺手想想：换作是我，我该如何管好这个项目？

比如，程序员可以锻炼良好的技术感知。应对不断发展的新技术，程序员无需掌握其所有细节。程序员只要结合工程经验，客观调研并回答一些关键问题：该技术解决了什么问题？怎么解决的？可以解决么？就可以对某项新技术有很好的判断。良好的技术感知，可以辅助程序员做出更好的架构决策。

甚至，不当程序员了！很多人加入程序员行业仅仅是看上了薪资，并不对技术感兴趣。可兴趣才是支撑一个人发展职业的最好动力。若知道技术并非自己的兴趣，那工作之余完全应该发展自己的兴趣爱好。况且，计算机技术是非常实用的，做程序员也不算蹉跎岁月。当程序员的经验，也许会在意想不到的时候，发挥作用。

总之，除了掌握具体的技术栈，程序员也需要注重锻炼技术以外的能力。积跬步以至千里，从当下开始点滴积累，程序员才能更充分地应对「35 岁危机」。

各位技术人，共勉！