一次数据迁移的完整复盘

这是我做过的最紧张的一次上线。8200 万行数据，从旧的表结构迁到新的，中间字段拆分、类型变更、还多了一张关联表。整个过程持续了 26 天，切流当晚我在公司待到凌晨 4 点。 结果是成功的，但过程中犯的错误足够写一篇长的。 背景和目标 旧表有个 extra 字段，是个 JSON 文本，塞了十几个业务
作者：咖啡不加糖
分类： 技术笔记

重构一个三千行的老函数

那个函数叫 process_order，3247 行，接了 11 个参数，其中 3 个是可选的 dict。它是我们系统里最重要也最没人敢碰的一段代码，跑了六年，经手过大概八任维护者，我是第九个。 接手它的原因很简单：我们要加一个「预售订单」类型，而所有人的第一反应都是「在那个大函数里再加个 if」。
作者：早睡失败者
分类： 技术笔记

错误处理：我见过的三种糟糕写法

接手别人的代码时，我有个习惯：先全局搜一下捕获异常的关键字，看看有多少处、都是怎么写的。这个数字和写法，基本能预判我接下来半年的排查体验。 下面三种是我遇到最多的，每一种我都亲自被坑过。 第一种：捕获之后打条日志就完事 典型长这样：捕获所有异常，记一行日志，然后什么都不做，方法正常返回。 它的毒性在
作者：晚风信箱
分类： 技术笔记

Docker 在开发环境里的正确用法

我们组新人入职时，我会先看一眼他怎么用 Docker。这不是什么考核，纯粹是因为这个东西的误用率实在太高了，而且误用之后的痛苦是慢性的——不会立刻炸，只会让你每天多浪费二十分钟。 最常见的误用只有一种：把容器当虚拟机使。 那个「什么都在容器里」的方案 典型症状是这样的：一个巨大的开发镜像，里面装了运
作者：咖啡不加糖
分类： 技术笔记

读源码的正确姿势

经常有人问我：源码到底该怎么读？我一般会先反问一句：你为什么要读它？ 这不是抬杠。因为这三种目的的读法完全不一样，混在一起就会变成「打开仓库、从第一个文件开始看、看两天放弃」的经典失败流程。我自己重复过至少五次。 目的一：解决一个具体的问题 这是最常见也最容易成功的情况，因为你有一个天然的入口。 我
作者：泡面星球
分类： 技术笔记

关于「重写」的诱惑

我这辈子提过五次重写，成功两次，失败两次，还有一次到今天也说不清算成功还是失败。这篇就讲这几件事，每件都有具体的数字和后果。 第一次：赢了，但赢得很险 那是一个订单状态机，最早是用一堆 if-else 写的，我接手时有 1400 行，17 个状态，我数出来 63 条状态转移分支。改一个需求平均要动
作者：泡面星球
分类： 技术笔记

消息队列选型的一点心得

同事：我们这个消息通知功能，要不要上个队列？ 我：现在什么量级？ 同事：一天大概两千条吧。 我：那先别上。 这段对话我几乎每年都要重复一次。不是说队列不好，是很多团队引入它的理由经不起追问。一天两千条、峰值不过每秒几条的场景，一张表加一个定时扫描就够了，还顺带白送你可查询、可重放、可人工改状态这三个
作者：键盘上的猫
分类： 技术笔记

前端性能优化：先测量，再优化

先说结论：我见过的前端性能优化里，至少有一半的力气花在了用户根本感知不到的地方。包括我自己。 那两天我省错了地方 三年前我接手一个后台管理系统，第一天打开就觉得慢。我当时的反应特别典型——立刻打开构建配置，开始琢磨怎么拆包、怎么按需引入、要不要把静态资源挪到边缘节点。折腾了两天，产物体积从 2.8M
作者：三分钟热度
分类： 技术笔记

从一次事故里学到的监控与告警

先把时间线摆出来，这比任何总结都有说服力。 19:12 某个上游依赖开始返回超时，我们的一个核心流程失败率从 0.2% 涨到 68%。 19:47 客服群里出现第一条用户反馈：提交没反应。 19:52 值班同事看到反馈，开始查。 20:20 定位到上游超时，开始降级。 20:35 降级生效，恢复正常
作者：阿柴不加班
分类： 技术笔记

接口设计：那些让调用方骂人的细节

「你们这个接口，成功的时候返回 data 是对象，失败的时候 data 是空字符串，我前端得写三层判断。」 这是三年前一个前端同事在群里发的原话。当时我还有点不服气，觉得「加个判断而已」。后来我自己去对接了几个外部接口，才彻底明白那种感受——接口设计的所有偷懒，最后都变成调用方代码里的 if。 这篇
作者：咖啡不加糖
分类： 技术笔记
共 44 篇文章
页