checklist
写代码 checklist
注意位置
注意顺序
注意初始化
注意返回值
注意注释
注意防御性编程
注意数据库性能
上线 checklist
代码变更 check 代码
配置变更 check 配置
系统变更注意上线顺序
依赖中间件变更注意配置中间件
配置中心配了吗
交互所有细节都实现了吗？
配监控和埋点
数据库变更了吗？
安全检查
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2019-02-13
所谓解耦
软件设计，必有单元/片段，不管他们叫做系统、层次、模块、类型和方法，都是为了在一个抽象颗粒度上分割复杂度，让我们降低思考的难度，并且进行团队协作。 我们在进行系统交互的时候，要尽量设计单元交叉点通过薄的中间层交互。也就是放弃直接性，拥抱间接性。 间接性的实现，就是契约、接口或者门面/桥接模式。这些实践的使用，可以轻易让我们切换层次之间的实现，而使变动不扩散出去。
2026-06-30
CI/CD 方法论的前世今生
软件工程有一条反直觉的规律：集成的频率越高，每次集成的痛苦越小。这条规律从 1990 年代末被 Kent Beck 写进极限编程的实践清单，到今天演化出一整套涵盖构建、测试、部署、发布的自动化体系。CI/CD 不是某一个工具或某一种流程，而是三十年工程实践反复迭代的产物。 持续集成的诞生（1996-2006） 极限编程与 CI 的起源 1996 年，Kent Beck 加入克莱斯勒公司的 C3（Chrysler Comprehensive Compensation System）项目。这个项目此前陷入僵局，Beck 将它作为极限编程（XP）的试验田，引入了十二条核心实践，持续集成是其中之一。CI 的核心主张很简单：开发者每天多次将代码集成到主干，每次集成都触发自动构建和测试。1999 年出版的《Extreme Programming Explained: Embrace Change》正式将 CI 确立为一个命名实践。 CI 要解决的问题在当时有一个形象的说法叫"集成地狱"（integration hell）——团队各自开发数周甚至数月，最后合并代码时发现冲突...
2026-06-12
持久 Agent：当任务活得比会话长
聊天式 agent 的生命周期等于一次会话：用户发起，模型循环，产出结果，上下文丢弃。持久 Agent（persistent agent / durable agent）指的是另一类系统：它承接的工作生命周期长于单次模型调用、长于单个上下文窗口、长于单个进程，甚至长于发起它的那台设备。 一个夜间跑依赖升级的 agent、一个跨三天迁移代码库的 agent、一个每周整理 issue 的 agent，都属于这一类。它们的共同点是：任务的时间尺度和会话的时间尺度脱钩了。这篇文章给「持久」下一个可操作的定义，并整理支撑它的三根支柱。 本文与已有文章的边界 已有文章 主要讨论 与本文的关系 ReAct：推理与行动交织的 Agent 循环原型 单条轨迹内的推理-行动循环 ReAct 是内环，本文讨论内环之外怎么让任务活下去 Agent 全景指南 Agent 范式演化与高可用 提供范式背景，本文聚焦持久性这一个维度 Goal 模式深度研究 完成谓词、循环停止条件 完成谓词决定持久任务什么时候可以死 Harness Engineering：长程 Agent 的工程化底...
2026-05-20
Harness Engineering：长程 Agent 的工程化底座
微信公众号文章《Harness Engineering：让AI Agent长程运行的秘密武器》抓住了一个很重要的行业拐点：Agent 讨论正在从“模型有多强”转向“系统怎么让模型可靠工作”。这个判断是对的，但如果只把 Harness Engineering 理解成“给 Agent 做记忆和交接班”，还是太窄。 更准确的定义是：Harness Engineering 是围绕模型构建一套可执行的工作环境、状态系统、工具边界、验证机制和反馈循环，让 Agent 能跨越单个上下文窗口，持续推进真实任务，并在失败时留下可恢复的证据。 这不是 Prompt Engineering 的升级版，也不是 Context Engineering 的别名。Prompt 解决一次请求怎么说，Context 解决一次请求里放什么，Harness 解决的是任务生命周期怎么被系统托住。 一、为什么 2026 年突然轮到 Harness OpenAI 在 2026 年 2 月发布的 Harness Engineering 文章里披露了一个内部实验：团队从空 Git 仓库开始，用 Codex 构建并发布一个内部...
2026-07-01
AI 是放大器不是方向：读 Adam Bender 谈软件生态学的 10 倍时刻
引子：10 倍代码不等于 10 倍工程 Google 首席软件工程师 Adam Bender 在 Google I/O 2026 的一场演讲里抛出大多数人还没来得及思考的问题：当 AI 把代码产出速度推到现有工程流程无法承载的地步，开发者生态系统里什么会最先垮掉？ 他的回答直白：今天构建软件的方式，在 10 倍速度下根本行不通。AI 时代的真正赢家不是产出最高的团队，而是基本功最扎实的那些人。AI 只负责放大，不负责方向。 这场演讲串起一个大多数人没听过的概念：软件生态学，对生产软件的社会技术生态系统进行整体性研究的学科。它要求不只看技术，还要看人、看文化、看组织里那些不成文的规则。 软件生态学：被忽视的整体视角 系统、生态系统与社会技术系统 要理解软件生态学，得先回到三个基础概念。 系统是一组相互关联的元素，按照一套规则运作，形成统一的整体。空调就是系统：恒温器知道目标温度，暖通空调负责升温或降温，房间温度合适了信号就停。 生态系统是特殊的系统，由相互依赖的行动者组成的动态网络，这些行动者与其环境共同演化，具有涌现行为和去中心化的自主性。关键点是，环境是系统的一部分，不能把两...
2026-02-07
API 兼容性设计
在软件工程中，API 兼容性是一个至关重要但又经常被忽视的问题。良好的兼容性设计能够确保系统的平滑演进，避免因 API 变更导致的客户端崩溃和服务中断。本文将从多个维度探讨 API 兼容性设计的最佳实践。 什么是 API 兼容性 API 兼容性分为两种类型： 向前兼容：旧版本的客户端能够与新版本的服务端正常通信。即服务端升级后，旧客户端仍能正常工作。 向后兼容：新版本的客户端能够与旧版本的服务端正常通信。即客户端升级后，旧服务端仍能提供服务。 在实际项目中，我们通常更关注向前兼容，因为服务端的升级往往不可控，而客户端的更新节奏各异。 破坏性变更的分类 破坏性变更是指会导致现有客户端无法正常工作的 API 变更。主要分为三类： 1. 接口签名变更 123456789// 变更前public interface UserService { User getUser(String userId);}// 变更后 - 破坏性变更public interface UserService { User getUser(String userId,...