35岁老码农的技术探索：从代码人生到深夜读JS源码
上周五晚上十一点，我正对着屏幕调试一个诡异的内存泄漏问题，老婆在隔壁房间喊：“你又在跟电脑谈恋爱？” 我苦笑了一下——这哪是恋爱，分明是“包办婚姻”，还得伺候好这位脾气古怪的“对象”。
今年35岁，写代码第13年。远程办公三年，家里书房成了我的“作战室”。没有办公室的喧嚣，但多了孩子的哭声、猫主子踩键盘的惊喜，以及偶尔断掉的Zoom会议。我依然在写代码，不是因为热爱到无法自拔（虽然确实有点上头），而是因为我相信：技术探索不是年轻人的专利，而是每个认真对待代码人生的程序员的日常修行。
被逼出来的技术探索
去年双11前两周，团队接到紧急需求：重构一个核心前端模块，要求性能提升40%，同时兼容老旧业务逻辑。产品经理拍着胸脯说：“这个需求很简单，就改个交互。” ——这话一听就知道要出事。
旧代码是典型的“祖传JavaScript”：全局变量满天飞、回调地狱三层嵌套、注释比代码还少。最离谱的是，有个函数叫 doSomething()，点进去发现它真的什么都做：发请求、改DOM、算价格、埋点……我当时就想砸键盘。
但骂归骂，活还得干。我翻出尘封已久的《JavaScript高级程序设计》（第四版），还有《你不知道的JavaScript》三部曲——这些书我早年看过，但当时只当故事书读，现在重读，每一章都像在照镜子：原来当年我写的烂代码，书里早就预警了！
从读书到读源码：技术深度的跃迁
光看书不够，得动手。我决定用 模块化 + 纯函数 + 异步流控制 重构整个逻辑。但怎么保证不引入新Bug？线上可是百万级用户啊。
于是，我开始啃开源项目的源码。比如 axios 的拦截器实现、lodash 的 debounce 源码、甚至 Vue 3 的响应式系统简化版。不是为了造轮子，而是理解高手是怎么组织代码、处理边界、写可测试逻辑的。
举个例子，以前我写防抖，大概这样：
let timer;
function handleInput() {
clearTimeout(timer);
timer = setTimeout(() => {
// do real work
}, 300);
}
看似没问题，但多个实例共享 timer 就崩了。后来在 lodash 源码里看到人家用闭包+返回新函数的方式，立刻恍然大悟：
function debounce(func, wait) {
let timeout;
return function executedFunction(...args) {
const later = () => {
timeout = null;
func(...args);
};
clearTimeout(timeout);
timeout = setTimeout(later, wait);
};
}
这种写法不仅可复用，还能独立管理每个实例的状态。代码可读性和可维护性，往往就藏在这种细节里。
实战中的权衡：不是所有新技术都香
当然，技术探索不是盲目追新。有次团队想上 Svelte，我说先别急。我花三天时间做了个 PoC（概念验证），对比 React 和 Svelte 在我们业务场景下的 bundle size、首屏时间、开发体验。
结果如下：
| 框架 | Bundle Size (gzip) | 首屏时间 (3G) | 团队上手成本 | 生态成熟度 |
|---|---|---|---|---|
| React | 42 KB | 1.8s | 低 | 高 |
| Svelte | 28 KB | 1.3s | 中高 | 中 |
数据很香，但考虑到团队大部分是 React 老兵，且现有工具链（如监控、错误上报）深度集成 React，最后我们决定局部试点，不全量替换。技术选型不是跑分比赛，而是在性能、人力、风险之间找平衡点。
代码人生：写给人看，顺便让机器执行
这些年我越来越信奉一句话：代码是写给人看的，只是恰好能被机器执行。
所以我在团队推行几条“土规矩”：
- 函数名不说人话不算提交（比如
processData改成calculateDiscountedPrice） - 每个 PR 必须附带使用场景说明（不是文档，就是一段自然语言描述）
- 复杂逻辑必须配单元测试，哪怕只有两行断言
有次新人问我：“哥，你这函数注释比代码还长，是不是太啰嗦了？” 我笑着回他：“等你半夜被 PagerDuty 叫醒修 Bug 时，就会感谢现在的啰嗦。”
技术探索的终极目的：解决问题
别误会，我不是反对学新东西。相反，我每周留出半天“探索时间”：看 RFC、试新库、跑 benchmark。但所有探索必须锚定一个问题。
比如最近研究 Web Workers，不是因为它酷，而是因为我们有个 Excel 导出功能卡到用户投诉。用 Worker 把计算挪到后台后，主线程流畅了，用户也不再骂娘。
再比如读《Effective TypeScript》，是因为项目类型混乱导致联调效率低。加了 strict mode + 类型守卫后，联调时间从两天缩到半天——技术债还一分，幸福感涨十分。
给还在路上的你
如果你也30+，还在写代码，别焦虑。年龄不是瓶颈，停止思考才是。
技术会变，框架会过时，但解决问题的能力、对代码的敬畏心、持续学习的习惯，这些才是真正的“硬通货”。
我书架上那本《代码大全》已经卷边了，旁边还堆着打印的 TC39 提案和手写的算法草稿。它们不是装饰品，是我对抗“油腻中年”的武器。
最后送大家一句我贴在显示器边的话：
“Don’t just write code that works. Write code that lasts.”
共勉。
评论 0