所谓解耦
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

2018-03-07
语义版本化问题
语义化版本 2.0.0 《语义化版本 2.0.0》,三段版本号语义: 版本格式:主版本号.次版本号.修订号(MAJOR.MINOR.PATCH),版本号递增规则如下: 主版本号(MAJOR):当你做了不兼容的 API 修改, 次版本号(MINOR):当你做了向下兼容的功能性新增, 修订号(PATCH):当你做了向下兼容的问题修正。 先行版本号及版本编译信息可以加到"主版本号.次版本号.修订号"的后面,作为延伸。例如 1.0.0-alpha、1.0.0-beta.1、1.0.0-0.3.7。 版本号的初始阶段 在主版本号为 0.x.y 的阶段,API 被认为是不稳定的,任何变更都可能发生。这个阶段的软件不应该被用于生产环境。1.0.0 的发布意味着公共 API 的正式定义,后续的版本号变更都基于这个公共 API 的变化来递增。 先行版本号(Pre-release) 先行版本号通过在修订号后面加上连字符和一系列以点分隔的标识符来表示。例如: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta < 1.0.0-b...

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(约定) ...

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

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

2018-10-26
checklist
写代码 checklist 注意位置 注意顺序 注意初始化 注意返回值 注意注释 注意防御性编程 注意数据库性能 上线 checklist 代码变更 check 代码 配置变更 check 配置 系统变更注意上线顺序 依赖中间件变更注意配置中间件 配置中心配了吗 交互所有细节都实现了吗? 配监控和埋点 数据库变更了吗? 安全检查

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





