所谓解耦
Created|Updated|工程实践
|Word Count:159|Reading Time:1mins|Post Views:
软件设计,必有单元/片段,不管他们叫做系统、层次、模块、类型和方法,都是为了在一个抽象颗粒度上分割复杂度,让我们降低思考的难度,并且进行团队协作。
我们在进行系统交互的时候,要尽量设计单元交叉点通过薄的中间层交互。也就是放弃直接性,拥抱间接性。
间接性的实现,就是契约、接口或者门面/桥接模式。这些实践的使用,可以轻易让我们切换层次之间的实现,而使变动不扩散出去。
Author: magicliang
Copyright Notice: All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles

2026-07-01
AI 是放大器不是方向:读 Adam Bender 谈软件生态学的 10 倍时刻
引子:10 倍代码不等于 10 倍工程 Google 首席软件工程师 Adam Bender 在 Google I/O 2026 的一场演讲里抛出大多数人还没来得及思考的问题:当 AI 把代码产出速度推到现有工程流程无法承载的地步,开发者生态系统里什么会最先垮掉? 他的回答直白:今天构建软件的方式,在 10 倍速度下根本行不通。AI 时代的真正赢家不是产出最高的团队,而是基本功最扎实的那些人。AI 只负责放大,不负责方向。 这场演讲串起一个大多数人没听过的概念:软件生态学,对生产软件的社会技术生态系统进行整体性研究的学科。它要求不只看技术,还要看人、看文化、看组织里那些不成文的规则。 软件生态学:被忽视的整体视角 系统、生态系统与社会技术系统 要理解软件生态学,得先回到三个基础概念。 系统是一组相互关联的元素,按照一套规则运作,形成统一的整体。空调就是系统:恒温器知道目标温度,暖通空调负责升温或降温,房间温度合适了信号就停。 生态系统是特殊的系统,由相互依赖的行动者组成的动态网络,这些行动者与其环境共同演化,具有涌现行为和去中心化的自主性。关键点是,环境是系统的一部分,不能把两...
2026-06-12
持久 Agent:当任务活得比会话长
聊天式 agent 的生命周期等于一次会话:用户发起,模型循环,产出结果,上下文丢弃。持久 Agent(persistent agent / durable agent)指的是另一类系统:它承接的工作生命周期长于单次模型调用、长于单个上下文窗口、长于单个进程,甚至长于发起它的那台设备。 一个夜间跑依赖升级的 agent、一个跨三天迁移代码库的 agent、一个每周整理 issue 的 agent,都属于这一类。它们的共同点是:任务的时间尺度和会话的时间尺度脱钩了。这篇文章给「持久」下一个可操作的定义,并整理支撑它的三根支柱。 本文与已有文章的边界 已有文章 主要讨论 与本文的关系 ReAct:推理与行动交织的 Agent 循环原型 单条轨迹内的推理-行动循环 ReAct 是内环,本文讨论内环之外怎么让任务活下去 Agent 全景指南 Agent 范式演化与高可用 提供范式背景,本文聚焦持久性这一个维度 Goal 模式深度研究 完成谓词、循环停止条件 完成谓词决定持久任务什么时候可以死 Harness Engineering:长程 Agent 的工程化底...
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-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,...
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-05-23
AI 不会吞掉软件,只会吞掉入口
“AI 会吞掉所有软件”这个说法很有传播力,但技术上不够准确。更可能发生的事情是:软件本体继续存在,软件入口被 AI 重写。 计算器、数据库、编译器、PDF 库、浏览器、CAD、CI、权限系统、ERP 不太会因为 LLM 出现而消失。它们处理的是确定性状态、格式、权限、计算和副作用。LLM 不适合直接替代这些系统,却很适合成为它们上方的意图入口。 从交互史看,GUI 的意义之一,是把人和计算机之间的操作鸿沟压低了。用户不必记住底层命令和数据结构,也能通过窗口、图标、菜单和指针操作复杂系统。Agent 时代出现的是另一道鸿沟:LLM 和传统软件之间的鸿沟。CLI、API、MCP 和 Skills 把这道鸿沟压低了,因为它们把软件能力变成模型能读、能调、能记录、能验证的文本接口。 确定性系统不会消失 裸模型不是确定性程序。它可以写出计算器代码,但不应该代替计算器执行财务计算;它可以解释 PDF 结构,但不应该靠想象修改 PDF 二进制;它可以生成 SQL,但实际执行、回滚、审计和加锁的仍然是数据库。 这不是模型能力不够强时的临时现象,而是范式边界。真实软件世界需要可复现、可审计、...
