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]
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2018-10-08
业务分析方法
背景 从 prd 出发，分析业务需求，寻找可以创造价值的方案。 业务分析的价值 全面分析用户的各项需求 告诉我们“做什么” 业务分析的目的 理解产品需求，识别业务范围 分析业务模块的重要程度、优先级 发现产品设计的不足 为后后续测试分析做准备 业务分析方法-整体过程 用不同的动作达到不同的产出。 理解 需求背景（必须） 举例：阿里巴巴账户体系 要初步阐述：1. 产生什么价值。 2. 需要解决什么问题。3. 甚至要阐明要达到什么目标（比如，基于支付宝账户体系统一账户id）。 现状分析（必须） 产品定位 现有业务架构 产品业务范围 规划业务架构**（1. 要有分期的意识，识别产品形态。 2. 要有清洗数据的方案，预测安全风险）** 识别（抽象分析建模） 业务角色（实际上就是系统交互的输入方，有多少个角色，就需要关注多少个东西） 自然人 其他系统 业务串联（为了找业务用例。业务串联就是把一堆文字描述串在一起） 业务用例（建模-业务用例图 用例是对场景的概括） 分析业务用例（建模-活动图 活动图是对用例的拆解） 提炼（进一步建模） 关键流程 由活动图的 ...
2026-07-01
AI 是放大器不是方向：读 Adam Bender 谈软件生态学的 10 倍时刻
引子：10 倍代码不等于 10 倍工程 Google 首席软件工程师 Adam Bender 在 Google I/O 2026 的一场演讲里抛出大多数人还没来得及思考的问题：当 AI 把代码产出速度推到现有工程流程无法承载的地步，开发者生态系统里什么会最先垮掉？ 他的回答直白：今天构建软件的方式，在 10 倍速度下根本行不通。AI 时代的真正赢家不是产出最高的团队，而是基本功最扎实的那些人。AI 只负责放大，不负责方向。 这场演讲串起一个大多数人没听过的概念：软件生态学，对生产软件的社会技术生态系统进行整体性研究的学科。它要求不只看技术，还要看人、看文化、看组织里那些不成文的规则。 flowchart TB subgraph Eco["社会技术生态系统（软件生态学的研究对象）"] direction LR Culture["工程文化<br/>组织结构 · 激励机制"] Practice["工程实践<br/>审查 · 测试 · 发布"] ...
2019-02-13
所谓解耦
软件设计，必有单元/片段，不管他们叫做系统、层次、模块、类型和方法，都是为了在一个抽象颗粒度上分割复杂度，让我们降低思考的难度，并且进行团队协作。 我们在进行系统交互的时候，要尽量设计单元交叉点通过薄的中间层交互。也就是放弃直接性，拥抱间接性。 间接性的实现，就是契约、接口或者门面/桥接模式。这些实践的使用，可以轻易让我们切换层次之间的实现，而使变动不扩散出去。
2026-06-14
Loop Engineering：从 Boris 的 /loops 到持久 Agent 工程
本文的 Loop Engineering 取工程视角：持久 Agent 自动化的工程抽象，包括定时触发、长期运行、多会话并发、可恢复状态、权限边界、验证证据和人工升级路径。Claude 官方在 Getting Started with loops 里给出的 4 种循环分类（Turn-based / Goal-based / Time-based / Proactive）是操作视角的互补坐标系，见后文「循环的 4 种触发形态」。 本文与已有文章的边界 本博客已有 Agent Loop、Ralph Loop、Goal、Harness Engineering、Hook 体系等相邻文章，本文专门讨论 Loop Engineering。和已有文章的边界： 已有文章 主要讨论 与本文的关系 AI Coding Agent 的 Hook、Loop 与插件体系 Codex、Claude Code、OpenCode、OMC 的运行时结构 写到 loop 与 hook，但没有以 /loops 和 Routines 的持久自动化为主线 Goal 模式深度研究 Goal、Ralp...
2026-07-14
为什么叫"测试夹具"：Fixture 的词源与跨领域漫游
测试夹具这个中文词带着工业感，让第一次听到它的开发者往往去搜索"是不是翻译错了"。词源确实如此：fixture 来自机械加工，后来进入电子测试领域，再由 Kent Beck 引入软件测试框架里。这个词在软件工程里覆盖的范围，也远比"单元测试"要宽。 从车间到代码 fixture 这个词在机械加工里有精确含义：在 CNC 车床或焊接台上，fixture 是一种工装，把工件固定在已知位置，让每次加工操作都从相同的起点开始。与 jig（引导刀具路径的夹具）不同，fixture 的职责只有一件事——把工件钳牢，消除定位误差。 词源上，fixture 来自拉丁语 figere（刺入、固定），经 fixura（固定物）演变为英语词汇，约在 16 世纪末进入法律语言，最初指"永久附着于不动产的动产"——嵌入墙体的管道、固定在地板上的书架，那些不能随意拆走的东西。 电子测试领域用法相似：一块 PCB 插入测试夹具后被固定在已知电气状态，探针才能重复施加相同的激励、在相同节点读取信号，排除接触不稳定的干扰。 三种用法的共同语义：将某个对象...
2026-05-23
Agent Teams 为什么有效
多 Agent 不是把同一个模型多开几份，也不是给系统加几个“人格”。它有效的地方，是把一个会互相稀释的上下文问题，拆成几个更窄、更干净、更容易验证的工作单元。 复杂任务不是信息越多越好。一个 Agent 同时负责需求、架构、编码、测试、文档和发布，很容易在同一个窗口里把角色、证据和目标搅在一起。Agent Teams 的价值，是让每个工作单元只面对一个足够小的世界。 注意力需要降维 考虑一个频谱分析的类比：复杂任务像一段混合信号，包含多个频率分量叠加。单 Agent 试图同时处理所有频率，相当于用一个宽带滤波器——信噪比低，各分量互相干扰。多 Agent 相当于用一组窄带滤波器，每个只提取自己负责的频段，互不干扰，最后再合成输出。 模型的注意力也有这个问题。任务越大，上下文里越容易同时出现目标、反例、日志、旧方案、失败尝试、代码片段和用户补充。它们都在争夺同一个窗口里的注意力。多 Agent 的第一层收益，就是把同一团上下文切成几个局部上下文。 flowchart TB U[用户目标] --> O[Orchestrator: 保持全局目标] O --&...
