checklist
写代码 checklist
注意位置
注意顺序
注意初始化
注意返回值
注意注释
注意防御性编程
注意数据库性能
上线 checklist
代码变更 check 代码
配置变更 check 配置
系统变更注意上线顺序
依赖中间件变更注意配置中间件
配置中心配了吗
交互所有细节都实现了吗？
配监控和埋点
数据库变更了吗？
安全检查
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
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）——团队各自开发数周甚至数月，最后合并代码时发现冲突...
2021-12-13
What is the best comment in source code you have ever encountered? [closed]
What is the best comment in source code you have ever encountered? [closed]
2018-05-09
Convention over Configuration over Programming
什么是 Convention over Configuration over Programming 在软件工程中，有一条重要的设计哲学层级： Convention over Configuration over Programming 约定优于配置，配置优于编程。 这条原则的核心思想是：能用约定解决的问题，就不要引入配置；能用配置解决的问题，就不要写代码。 它反映了软件设计中对复杂度管理的追求——越是高层次的抽象，使用成本越低，出错概率也越小。 三个层次的含义 Programming（编程） 编程是最灵活但成本最高的方式。开发者需要编写具体的代码逻辑来实现功能。每一行代码都是潜在的 bug 来源，都需要测试、维护和 review。编程适合处理那些真正需要定制化逻辑的场景。 Configuration（配置） 配置是介于约定和编程之间的中间层。通过外部化的配置文件（如 XML、YAML、properties 等），开发者可以在不修改代码的情况下改变程序行为。配置降低了修改成本，但引入了配置管理的复杂度——配置项越多，理解和维护系统的难度就越大。 Convention（约定） ...
2026-05-23
上下文换入换出：下一代 scaling
上一篇说裸模型像抽卡，因为它把概率输出直接暴露给用户。抽卡感解释的是一次任务里的波动；上下文问题解释的是长程任务为什么会累、会乱、会跑偏。 LLM 和人都有一个共同约束：它们都在上下文里工作。区别在于，模型的上下文 refill 是读写问题，人的上下文 refill 是注意力问题。机器可以把一段摘要重新塞进 message array，人却要重新把目标、材料、约束和下一步动作装回工作记忆。这个过程有磨损。 人也有 context window 把 LLM 说成统计模型是对的，但这种说法容易遮住它和人的相似工作形态。人从长期通识积累到领域学习，再到职业训练和反馈，很像预训练、继续预训练和后训练的分层。拥有推理能力以后，人也不是在真空中推理，而是在一个被任务材料填充出来的上下文里推理。 上下文质量决定注意力预算能不能被调动。APA 对 multitasking 的综述把任务切换带来的时间成本叫 switching costs。换到工程语境里，context switching 的问题不是“同时做两件事”这么简单，而是每次切换都要重新加载一组任务状态：目标是什么，做到哪里，哪些约束不...
2026-05-23
裸模型为什么像抽卡
大模型写代码有一种很危险的爽感：同一个问题，上一轮胡说八道，下一轮突然给出一段漂亮实现。失败的时候像差一点，成功的时候像中奖了。 这种体验很像抽卡。不是因为使用 AI 等同于赌博，而是因为裸模型的反馈结构具备几个相似特征：结果有波动，高分样本偶尔出现，用户很难提前判断下一轮是不是高分，于是自然产生“再试一次”的冲动。 把这种冲动看清楚，比单纯争论模型聪不聪明更重要。很多 AI coding 的燃尽感，不来自模型太弱，而来自人把自己的注意力押在一次又一次低可见度的重试上。工程工作被悄悄改造成了抽卡循环。 flowchart LR A[一次任务] --> B[裸模型采样] B --> C{输出质量} C -->|低分| D[补 prompt / 换模型 / 重试] C -->|高分| E[强奖励: 这次出货了] D --> B E --> F[提高下一轮期望] F --> D D --> G[隐藏成本: review / 归因 / 修复 / 焦虑] ...
2018-10-08
业务分析方法
背景 从 prd 出发，分析业务需求，寻找可以创造价值的方案。 业务分析的价值 全面分析用户的各项需求 告诉我们“做什么” 业务分析的目的 理解产品需求，识别业务范围 分析业务模块的重要程度、优先级 发现产品设计的不足 为后后续测试分析做准备 业务分析方法-整体过程 用不同的动作达到不同的产出。 理解 需求背景（必须） 举例：阿里巴巴账户体系 要初步阐述：1. 产生什么价值。 2. 需要解决什么问题。3. 甚至要阐明要达到什么目标（比如，基于支付宝账户体系统一账户id）。 现状分析（必须） 产品定位 现有业务架构 产品业务范围 规划业务架构**（1. 要有分期的意识，识别产品形态。 2. 要有清洗数据的方案，预测安全风险）** 识别（抽象分析建模） 业务角色（实际上就是系统交互的输入方，有多少个角色，就需要关注多少个东西） 自然人 其他系统 业务串联（为了找业务用例。业务串联就是把一堆文字描述串在一起） 业务用例（建模-业务用例图 用例是对场景的概括） 分析业务用例（建模-活动图 活动图是对用例的拆解） 提炼（进一步建模） 关键流程 由活动图的 ...