说句实话这个创作纪念日本来没打算专门写点什么。直到前几天打开后台看到创作日历上的数字已经攒到了某个整数又恰好撞上 1024 程序员节两个数字叠在一起我突然觉得应该停下来认真做一次技术成长回顾。这种整数节点对技术人来说就像代码里的 Tag——平时不打不知道最近到底攒了多少东西打了以后才发现自己的技术积累其实已经漂移了好几个主版本。这篇内容算是我给自己的一份年度复盘记录过去几年从只会让功能跑起来到开始关心性能、稳定性和长期维护中间踩过不少坑也沉淀出几条能复用的方法论。如果你也在坚持写技术博客或者刚工作一两年正处于每天都在忙但好像没长进的迷茫期这篇应该能给你一些参考。文章中不会涉及具体业务细节全是通用的成长经验和实操技巧可以直接复制到自己的复盘流程里用。1. 为什么我会选在1024这天写一篇年度复盘1.1 1024 对技术人来说不只是个数字1024 在技术圈几乎等同于程序员节它是 2 的十次方是二进制世界的进位节点也是很多系统做容量估算时的默认刻度。对普通用户来说这就是日历上平平无奇的一个日期但长期跟存储容量、索引结构、分片逻辑打交道的技术人看到 1024 会本能地想到单位换算、资源上限、性能边界这类事情。我自己更愿意把 1024 理解成版本管理的打 Tag 时刻。一个项目发版本时都要打 Tag、写 CHANGELOG否则几个月后回头看根本说不清某个功能是哪次迭代引入的。技术人的成长也一样——平时只顾着往前赶需求很少有人主动停下来问自己过去这段时间我的知识体系到底升了几个小版本借助 1024 这个天然具有程序员色彩的纪念日正好逼自己做一次彻底的回溯看看哪些积累是真实可复用的哪些只是看起来很忙。1.2 把复盘当成一次自我代码评审我一直觉得个人复盘和 Code Review 在结构上高度相似。Code Review 会检查整体架构是否清晰、有没有重复逻辑、有没有隐藏的坏味道复盘也该这样。我的做法是准备一份固定模板每年或每半年过一遍技术复盘模板 - 时间窗口过去 18 个月 - 参与项目6 个3 个从零搭建2 个重构1 个长期维护 - 核心技术栈Go / PostgreSQL / Redis / Docker - 关键事件一次线上偶发超时事故、一次大表迁移、一次重构收益不明显 - 知识体系坏味道对操作系统底层理解停留在表面 - 重复出现的坑3 次因为忽略边界条件导致返工 - 下一年要做的重构把分散的笔记整理成专题问题维度也照搬代码评审的思路知识结构有没有到处重复有没有用大量特殊规则去掩盖设计缺陷哪些努力属于局部优化哪些问题需要整体重构用这套框架重新看自己很多平时察觉不到的问题一下就暴露出来了。这也是我建议每个技术人定期做的一件事不是简单写今年学了什么而是像评审别人的代码一样毫不留情地质疑自己。2. 从能跑到能扛这几个阶段我到底是怎么走过来的2.1 第一阶段能跑是及格线刚接触开发的阶段我最重要的目标就一个让功能跑通。需求下来先找类似实现搜索现成代码片段拼接口、调参数只要页面能点、接口能返回数据就觉得这个任务完成了。这个阶段最大的特征是知其然不知其所以然——我知道配置某一项就能解决报错但完全不理解底层发生了什么。那时候收获的不是深度而是广度。因为什么都敢试所以快速接触了前端交互、后端接口、数据库表设计、部署脚本等多个环节对整个系统怎么运转有了大致轮廓。但副作用也很明显知识碎片化严重今天靠记忆学会的东西明天换个场景就失效。每次踩为什么按文档写还是报错这种坑时我都会隐约意识到自己缺的不是步骤而是原理。这个阶段大约持续了半年多真正推动我往深走的是一次线上故障。2.2 第二阶段从一个人能扛到系统能扛转折发生在维护某个内部系统的时候。某天开始系统在高并发时段偶发超时错误率不高大约 2%但就是隔几分钟冒一次。最开始我以为只是网络抖动加了一台机器没好转又以为是代码逻辑问题肉眼扫了几遍核心链路也没发现问题。后来是同事提醒我别只盯着业务代码去看看资源层。我这才发现数据库连接池的最大连接数设置得太低平时流量小时完全没事一旦高峰期请求量上来连接被占满后续请求只能排队等连接等待超过阈值就报错。这个问题的根因跟业务逻辑毫无关系纯粹是容量参数配错了。那次排障给我上了一课一个系统能不能长期站稳看的不是功能丰富度而是它在边界条件下怎么表现。从那以后我学习的主线从怎么实现功能转移到了怎么保证功能稳定——开始学超时、重试、熔断、连接池、监控告警这些内容。也就是从这一阶段起我逐渐理解了一个技术人的价值不只是写出能跑的代码更是让系统在异常来临时依然不死、不慢、不错。2.3 第三阶段主动设计控制复杂度到了第三个阶段我面对需求时不再直接动手写代码而是先画数据流转图先问几个问题这个功能未来半年会不会扩展当前模块的耦合会不会拖慢后续迭代如果数据量翻十倍方案还成立吗这种思维转变源于一个重构项目。当时接手一个历史功能代码本身能工作但为了兼容各种特殊情况里面塞了无数 if 分支。加一个小需求要牵扯五六个地方同步修改每次上线都提心吊胆。后来我花了一个迭代周期做重构把公共逻辑抽象出来让各个分支依赖统一接口最终整个模块的代码量减少了接近一半后续迭代效率明显提升。这件事让我彻底理解了控制复杂度的重要性。技术成长到了一定程度比的不再是谁敢写而是谁会克制。能用简单的数据结构和清晰的分层解决的问题就不要引入复杂的中间件能由标准库完成的事就不要为了用框架而用框架。为了理清这个过程我会定期做记录对比整理成下面这个表格用来提醒自己当前处于哪个阶段、下一阶段该关注什么。成长阶段核心关注点典型表现突破契机能跑功能是否完成拼代码、试参数、跑通即交付遇到文档解决不了的报错能扛系统是否稳定关注限额、监控、边界条件一次线上偶发故障能设计长期是否好维护画架构图、做方案对比、主动重构一个难以扩展的历史模块3. 复盘这些年真正改变我技术路线的三件事3.1 把写文章当成一项开发任务很多人问我为什么能坚持写技术内容这么久我的答案有点奇怪我把写文章当成开发任务来管理而不是等灵感。每篇文章都有明确的需求背景、技术方案、验收标准和 release note流程跟做一个小功能没有本质区别。具体来说我写一篇技术干货会卡五个段落背景说明为什么要做这件事具体做法和关键步骤参数或代码的细节解释验证结果与对比数据最后是踩过的坑和注意事项。这个结构看起来很简单但真正坚持下来后我发现它倒逼我做了一件非常重要的事——把每个模糊的判断变成可验证的结论。比如写某个方案选型时我必须说清楚为什么选 A 不选 B背后的数据是什么写性能优化时必须给出优化前后的对比不能只写速度提升了。写作更像一次极端测试如果我不能用文字把某个技术点讲明白大概率是我自己也没完全懂。很多我以为自己已经掌握的知识都是写着写着发现漏洞回头重新再看源码才补齐的。从这个角度看写作本身已经成为我最稳定的深度学习工具它远比看一遍别人的博客有效得多。3.2 从修 Bug 到让 Bug 无处可生前面提到的偶发超时事故是我技术路线上很重要的一个分水岭值得单独复盘一遍完整的排查链路。当时的问题表现和排查路径大概是这样的现象高峰期偶发超时错误率约 2%复现极难。排查过程先看服务整体的 CPU、内存、磁盘 IO指标都正常排除资源耗尽。在核心链路逐步加入耗时日志确认瓶颈集中在数据库调用环节。检查数据库实例本身慢查询日志也没有明显异常排除了单条 SQL 的问题。最终定位到连接池参数最大连接数设置过低高并发下部分请求获取连接需要排队排队超过设定阈值就抛出超时异常。修复方式调大连接池上限同时增加连接等待时长监控并配置告警。这个案例给我留下的方法论不只是一个参数配置而是一整套排查思路先看资源层再看应用层最后才看业务逻辑能用数据定位的不靠肉眼猜。之前我遇到 Bug 的第一反应是打开代码反复读现在我的第一反应是看监控、看指标、看日志用数据把问题范围一步步缩小。从揪出 Bug转换到让 Bug 无处可生本质上就是从防御式地想问题变成主动设计可观测性、可诊断性的系统。3.3 参与一个内部工具的维护与开源化第三件改变我技术路线的事是参与维护一个团队内部使用的命令行小工具。最开始它只是我为了偷懒写的几十行脚本用来定时清理临时目录和归档日志。后来同事觉得好用陆续提了一些功能需求于是我开始认真设计它的参数解析、错误处理和输出格式再后来由于需要支持不同平台我又主动去读了相关语言标准库的实现源码补齐了很多底层知识。这个过程和单纯写业务功能完全不同内部工具面向真实用户需要处理各种奇怪的输入开源化以后还要考虑跨平台兼容和版本迭代。为了处理用户反馈我学会了如何复现问题、如何写最小化复现示例、如何礼貌又准确地回复 issue。这些软技能没有直接体现在代码量上却实打实提高了我的工程素养。现在回看这个无心插柳的小工具让我第一次完整走了一遍设计、实现、发布、收集反馈、迭代的闭环也让我明白技术人不该只做功能的消费者更应该做生态的参与者。4. 回看踩过的坑几条从疼里总结出的经验4.1 文档与注释的债迟早要连本带利还曾经接手过一个对接项目对方接口文档常年不更新很多字段靠群里语音沟通确认代码注释几乎为零。结果每次联调都要靠猜猜错了就返工三个月里同一个接口来来回回改了四遍。后来我们强制要求任何接口变更必须同步更新文档代码里必须写明为什么这么写而不仅是写了什么。这条经验放在个人成长上也成立。往自己的笔记仓库里写东西时如果只记结论、不记原因和上下文三个月后再看跟没记一样。我现在做知识点笔记会用统一格式触发场景、踩坑过程、根因、最终解法、一句话总结。这个习惯让我回看笔记的效率提升了非常多也减少了大量重复查资料的时间。4.2 过早优化的诱惑性价比其实极低有一段时间我特别迷恋性能优化觉得把某个查询从 5 秒优化到 100 毫秒特别有成就感。后来复盘才发现那些被我精心优化的功能有的一个月都调不了几次真正高频使用的页面反而因为没把时间用上去体验一直普通。这就是典型的局部优化偏差我花大力气优化的东西用户的体感收益是零。这条坑的教训后来被我提炼成一句自我提醒先量化再优化。每次有忍不住要优化的冲动时先问三个问题——这个路径是高频路径吗当前数据支撑慢这个结论吗优化之后怎么验证用这三个问题过滤掉绝大多数性价比低的优化冲动把时间留给真正影响体验的功能。4.3 技术选型时流行是最不值钱的指标参与某个项目启动时团队就技术方案发生了不少讨论。有人提出要用某个刚发布不久的新技术理由是社区讨论度很高。我坚持用的是团队已经熟练、生态稳定的方案理由是新方案能不能支撑业务不确定团队成员能不能快速上手也不确定唯一的确定是学习成本。事实证明这个决策帮项目省了很多时间。后来的社区动态也印证了新方案虽然很有潜力但在当时的版本下存在几个明显的问题如果盲目跟进团队大概率会陷入填坑的循环。技术选型本质上是管理风险不是追逐热点。稳定的旧工具配合清晰的设计远胜于花哨的新工具配合混乱的架构。踩过的坑当时的想法现在的做法文档和注释欠债先跑通功能文档以后补变更必改文档记录原因过早优化性能指标好看就是成功先量化收益再决定是否优化追逐新技术新的一定比旧的好评估风险、团队能力、生态成熟度5. 接下来的技术方向与创作规划5.1 技术深度的三个支点展望接下来的时间我给自己的技术成长确定了三个支点。第一个支点是补基础。过去几年大量时间花在框架和工具上虽然用得很顺手但遇到需要深入底层的问题时明显感到吃力。接下来的计划是把计算机网络、操作系统和数据库原理重新过一遍每学完一个模块就用一篇文章把它输出用输出倒逼输入。第二个支点是刻意接触一个离日常业务远一点的领域。长期做同一种业务会让思维定型换个领域可以带来很多跨界启发。我计划业余时间系统地学一些编译原理相关的内容不是为了转行而是为了理解一门语言是如何把高级代码变成机器指令的这能帮我写出更符合语言设计意图的代码。第三个支点是教学化重构。把过去零散的项目经验整理成有教学价值的完整案例从需求分析、方案设计到关键代码实现和测试验证形成一套可以给别人参考的通关文档。这个过程逼我把隐性知识显性化对项目的理解层次完全不同。5.2 内容创作上的思路调整过去几年写的技术内容比较随意今天看到什么问题就写什么问题知识之间缺乏串联。接下来我准备放弃一部分单点技巧式的内容转向做专题型系列。比如我计划用几个月的周末时间完成一个围绕保障系统稳定性的系列把超时控制、重试策略、限流算法、连接池调优、监控告警设计等内容串成一条线。系列比单篇的难度大很多因为要照顾到前后文的逻辑衔接还要保证每一篇单独拿出来也有价值。但它带来的沉淀也更集中读者按顺序读下来可以完成一次成体系的认知升级。在内容形式上我还会刻意增加失败案例的比例。技术社区里展示成功太容易了但真正对读者有参考价值的往往是那些过程曲折、包含大量错误判断的复盘记录。把自己踩过的坑、做过的错误决策摆出来不仅是对读者的诚实也是对自己的进一步审视。技术上长期主义的最好策略就是持续做那些短期没有收益、长期却会不断复利的事情——内容创作和基础技术学习都是。这次复盘下来我最大的体会是技术成长不是一条匀速上升的曲线而是由几个关键转折点组成的。对我而言转折点分别是一次线上事故、一次重构和一个个人小工具。它们有一个共同特征都发生在任务边界模糊、没有现成方案可抄的场景里被迫自己去思考本质。如果你也正处于每天写业务代码但感觉不到进步的阶段不妨试着主动给自己制造类似的非日常任务写一篇有深度的复盘维护一个自己的小工具或者把一个用过的技术彻底讲透。给自己打这个 Tag 吧过半年再回头你会看到版本号确实在涨而且涨得比想象中快。