所谓解耦
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-02-07
变更日志(Changelog)规范
什么是变更日志 变更日志(Changelog)是一个按时间顺序记录项目所有重要变更的文件。它帮助用户、开发者和利益相关者了解每个版本中发生了什么变化,包括新功能、Bug 修复、破坏性变更等。 为什么需要变更日志 用户友好:让用户快速了解新功能、修复的问题和需要注意的变更 版本追溯:帮助定位问题首次出现或修复的版本 团队协作:统一团队对变更的理解和沟通 发布管理:辅助版本发布流程和发布说明的撰写 与 Git Log 的区别 特性 变更日志 Git Log 目标受众 用户、开发者、利益相关者 开发者 内容粒度 功能级别的高级描述 每次提交的详细记录 可读性 高度结构化、易于阅读 技术性强、包含实现细节 维护方式 手动维护或自动化生成 自动记录所有提交 版本关联 按版本组织 按时间顺序 Git Log 记录所有的代码提交,包括内部重构、测试调整等;而变更日志只记录对用户有意义的变更。 Keep a Changelog 规范 Keep a Changelog 是目前最广泛采用的变更日志规范,由 Olivier Lacan 创建。 变更类型分类 Ke...

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-10-08
业务分析方法
背景 从 prd 出发,分析业务需求,寻找可以创造价值的方案。 业务分析的价值 全面分析用户的各项需求 告诉我们“做什么” 业务分析的目的 理解产品需求,识别业务范围 分析业务模块的重要程度、优先级 发现产品设计的不足 为后后续测试分析做准备 业务分析方法-整体过程 用不同的动作达到不同的产出。 理解 需求背景(必须) 举例:阿里巴巴账户体系 要初步阐述:1. 产生什么价值。 2. 需要解决什么问题。3. 甚至要阐明要达到什么目标(比如,基于支付宝账户体系统一账户id)。 现状分析(必须) 产品定位 现有业务架构 产品业务范围 规划业务架构**(1. 要有分期的意识,识别产品形态。 2. 要有清洗数据的方案,预测安全风险)** 识别(抽象分析建模) 业务角色(实际上就是系统交互的输入方,有多少个角色,就需要关注多少个东西) 自然人 其他系统 业务串联(为了找业务用例。业务串联就是把一堆文字描述串在一起) 业务用例(建模-业务用例图 用例是对场景的概括) 分析业务用例(建模-活动图 活动图是对用例的拆解) 提炼(进一步建模) 关键流程 由活动图的 ...

2018-10-08
系分方法论交流笔记
分析、设计和架构的区别 系分 = 业务分析 + 系统设计 系分其实就是 Analysis + Design 业务分析才是最重要的大头 要理解: 架构约束 项目约束 要有: 权衡 选择 的过程 理解业务,要理解业务背后的东西,产出的是模型。 一步一步走,推演出来解决方案,要有方法论。 系统设计是很明确的工作了 应用设计 + 数据设计 + 技术设计 = 系统方案 要考虑的额外问题: 非功能设计:运行关注点、运维关注点、开发关注点、测试关注点。 项目约束 常见方法论 用例驱动设计 SOAD 面向服务的分析和设计 OOAD 面向对象分析和设计 DDD 领域驱动设计 DDD特别适合复杂系统。有一个以不变应万变的对象,才可以在未来承载复杂的业务演进过程。 这几种方法论可以混合使用。 需求分析与业务建模 把 prd 从薄读到厚,把文档中缺失的部分补全。 系分做 PRD 评审的时候,影响比较大的点一定要尽早确认。一些对系统变化可控,可预测的变化,可以暂时放过,后续在补充。 面向服务的业务建模 分析主业务服务,设计业务功能域,设计业务功能域边界。这个过程可能不断地螺旋式地重构。 如果用...

2019-12-13
CI/CD 方法论
CI/CD 的重要性 Martin Fowler说过,“持续集成并不能消除Bug,而是让它们非常容易发现和改正。” 持续集成和持续交付作为敏捷开发的一种最佳实践,通过包括构建、部署、测试、发布流程的自动化,实现质量内建,让质量问题可以快速发现和消除,从而提升软件交付的质量和效率。 基本策略 分支模型是CICD落地的源头,研发过程各角色间的协作方式以及研发过程内代码版本的流转方式都取决于分支模型。 首先划分环境。 划分环境后设计分支,注重开发和发布两个场景。 根据分支设计流水线,验证应该发生在全流水线里。 一般的分支模型 参考文献: 《在阿里,我们如何管理代码分支?》 《What is Trunk-Based Development?》 《提升团队的微服务落地能力》

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(约定) ...
Announcement
人生只是,守株待兔





