配置文件里的空格
缩进差一个空格,服务启动时报了一个和缩进毫无关系的错。现在养成了习惯: 改完配置先跑一遍解析校验,再看业务日志。
Personal Dev Journal
一个人写代码的地方。这里留着每天真正动手做过的事:写坏的构建脚本、读了一半的源码、 凌晨两点才想通的那个空指针,以及后来终于跑通的那组测试。写得慢,但基本都真实发生过。
我叫阿德里,做后端和工具链方向的工作。白天写业务代码,晚上折腾那些「看起来没产出但很有意思」的东西: 编译器的报错信息、一个 HTTP 请求到底经过了哪些层、为什么同样的配置换台机器就跑不起来。
最开始写日志是因为忘性大。同一个坑踩第二遍的时候,我翻回自己三个月前的记录,看到当时写下的一句话 ——「别在 CI 里用 shell 拼字符串」——然后省了两个小时。后来就慢慢写成了习惯, 从最开始的几句备忘,变成现在带上下文、带复现步骤、带失败方案的完整笔记。
这里不放简历、不接广告、不做课程。写下来的东西只对一类人有用:正在做类似的事、 刚好卡在类似的地方的人。如果某篇记录让你少花半小时,那它就没白写。
花了两个晚上,把四台机器上各不相同的那套依赖收拢成一个镜像。中间最麻烦的不是写构建文件, 而是搞清楚旧环境里那个从没写进文档的环境变量到底从哪来的。最后靠对比进程环境变量列表找到了。
接口从 80ms 掉到 1.4s,日志里什么都看不出来。最后定位到一条看起来毫无问题的关联查询: 索引其实建了,但字段的字符集和另一张表不一致,整个索引被放弃。改字符集,恢复。
之前一直以为自己对异步模型的理解没问题,直到写了一个在微任务里递归的循环,把页面卡死了。 这次认真读了规范里的执行顺序,顺手把几个常见误解整理成了一篇笔记。
一个跑了三年的项目,改动全靠手点。先从最容易出错的那三个模块下手,写了 60 多个用例, 第一天就抓出两个一直存在却从没被发现的边界问题。
散落在十几个文件夹里的临时脚本,终于被归到了一起。统一了参数风格,加了使用说明, 现在开新项目不用再复制粘贴那一堆自己也看不懂的旧代码了。
缩进差一个空格,服务启动时报了一个和缩进毫无关系的错。现在养成了习惯: 改完配置先跑一遍解析校验,再看业务日志。
统计报表的数字对不上,原因是服务容器跑在 UTC,而业务逻辑默认按本地时间取当天。 统一在入口处显式声明时区之后,问题消失。
一个缓存对象被多个请求同时改写,偶发数据错乱且极难复现。改成不可变结构之后, 这类问题再没出现过。
本地能跑、线上报错,排查到最后是小版本号依赖被自动升级了。 现在所有环境的依赖版本都写在锁文件里,构建前强制校验。
同时读的东西不会超过三样,多了就都读不进去。习惯是:先看官方文档把概念过一遍, 再找一个真实项目的源码对着读,最后用自己的话写一遍——写不出来的部分,就是还没懂的部分。
今年重点补的是两件事:数据存储的底层原理,以及 怎么把复杂系统拆成能独立测试的小块。前者解释了很多「为什么这样设计」, 后者直接改变了写代码的顺序。