从实习生到合格后端半年技术成长的客观复盘一、半年前的我 vs 现在的我半年前刚入职时写代码的标准是能跑就行。一个 200 行的函数、没有单元测试、没有异常处理——但功能上能调通自认为已经完成了任务。半年后回头再看那段代码发现的问题自己都脸红。这篇文章不是为了记录个人经历而是复盘这半年里技术成长的几个关键转折点。每一个转折都对应着一种思维方式的转变。二、五个关键转折点flowchart LR A[入职: 代码能跑] -- B[2个月: 代码可读] B -- C[3个月: 代码可测] C -- D[4个月: 代码可扩展] D -- E[6个月: 系统可观测] A -- A1[关注点: 功能正确性] B -- B1[关注点: 命名、结构、注释] C -- C1[关注点: 单元测试、边界处理] D -- D1[关注点: 抽象层次、接口设计] E -- E1[关注点: 监控、日志、告警]三、每个阶段的复盘转折 1从能跑到可读第 1-2 个月# 第 1 个月的代码风格 def f(x, y): a [] for i in range(len(x)): if x[i] 0: a.append(x[i]) z 0 for j in a: if j y: z 1 return z # 第 2 个月的代码风格同样的逻辑 def count_exceeding_threshold(numbers: list[int], threshold: int) - int: 统计数组中大于阈值的正数个数 positive_numbers [num for num in numbers if num 0] return sum(1 for num in positive_numbers if num threshold)触发这个转变的是一次 Code Review 中被 mentor 指出了变量命名问题。当时不以为然觉得功能对了就行。后来自己维护自己一个月前的代码时花了 20 分钟才看懂逻辑——从那时开始重视可读性。转折 2从可读到可测第 3 个月写了一堆看起来不错但无法独立测试的代码。逻辑和数据访问耦合在一起想测试业务逻辑必须启动数据库。学会写单元测试后发现一个有意思的现象写好测试的代码本身结构也会变好。因为想测试就得解耦解耦后的代码天然更模块化。测试不是负担是代码质量的强迫机制。转折 3从可测到可扩展第 4 个月开始接触到接口设计、依赖注入、策略模式等概念。不是因为面试要考而是遇到了真实的需求变更对接了多个支付渠道每个渠道的退款逻辑都不一样。最简单的实现是在if channel alipay这种分支里堆代码。但随着渠道从 2 个变成 5 个这个函数变成了 500 行的 if-else 地狱。重构为策略模式后新增一个渠道只需要加一个类不影响已有代码。转折 4从可扩展到可观测第 5-6 个月线上出了一次 P0 故障排查耗时 2 小时——因为日志不全、没有关键指标监控。那次之后开始有意识地在关键路径上加日志、在重要指标上加监控。代码写完不只是能跑还要确保跑得怎么样你能第一时间知道。四、尚未跨越的坎实事求是地说有几个领域还在学习中分布式系统的一致性理论看了一些但实际系统设计经验不够。性能调优的直觉目前依赖 profiling 工具还没有形成一看代码就知道瓶颈在哪的直觉。架构决策的全局视角在单模块内能做好的决策越来越顺手但跨模块的系统级决策还缺乏经验。这些是下一个半年的目标。五、总结半年成长的体会可以归结为一句话代码能力的提升不是代码行数的累积而是思维方式的刷新。能跑是一维思维只关注功能可观测是多维思维功能、性能、稳定性、可维护性同时关注。每一次思维刷新背后都是一个真实的踩坑经历——线上故障、Code Review 的批评、重构的痛苦。这些经历比看任何教程都深刻。