SoftwareEngineering-CheatSheet

返回目录

Software Engineering & Architecture CheatSheet | 软件工程与架构导论

系统泛指由一群有关联的个体组成,根据某种规则运作,能完成个别元件不能单独完成的工作的群体。子系统也是由一群有关联的个体所组成的系统,多半会是更大系统中的一部分。

关联:系统是由一群有关联的个体组成的,没有关联的个体堆在一起不能成为一个系统。例如,把一个发动机和一台 PC 放在一起不能称之为一个系统,把发动机、底盘、轮胎、车架组合起来才能成为一台汽车。

规则:系统内的个体需要按照指定的规则运作,而不是单个个体各自为政。规则规定了系统内个体分工和协作的方式。例如,汽车发动机负责产生动力,然后通过变速器和传动轴,将动力输出到车轮上,从而驱动汽车前进。

能力:系统能力与个体能力有本质的差别,系统能力不是个体能力之和,而是产生了新的能力。例如,汽车能够载重前进,而发动机、变速器、传动轴、车轮本身都不具备这样的能力。

模块与组件

软件模块(Module)是一套一致而互相有紧密关连的软件组织。它分别包含了程序和数据结构两部分。现代软件开发往往利用模块作为合成的单位。模块的接口表达了由该模块提供的功能和调用它时所需的元素。模块是可能分开被编写的单位。这使它们可再用和允许人员同时协作、编写及研究不同的模块。

软件组件定义为自包含的、可编程的、可重用的、与语言无关的软件单元,软件组件可以很容易被用于组装应用程序中。模块和组件都是系统的组成部分,只是从不同的角度拆分系统而已。

从逻辑的角度来拆分系统后,得到的单元就是“模块”;从物理的角度来拆分系统后,得到的单元就是“组件”。划分模块的主要目的是职责分离;划分组件的主要目的是单元复用。其实,“组件”的英文 component 也可翻译成中文的“零件”一词,“零件”更容易理解一些,“零件”是一个物理的概念,并且具备“独立且可替换”的特点。

框架与架构

软件框架(Software framework)通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范,也指为了实现某个软件组件规范时,提供规范所要求之基础功能的软件产品。框架是组件规范,提供基础功能的产品。

软件架构指软件系统的顶层结构。首先,“系统是一群关联个体组成”,这些“个体”可以是“子系统”“模块”“组件”等;架构需要明确系统包含哪些“个体”。

其次,系统中的个体需要“根据某种规则”运作,架构需要明确个体运作和协作的规则。

第三,维基百科定义的架构用到了“基础结构”这个说法,我改为“顶层结构”,可以更好地区分系统和子系统,避免将系统架构和子系统架构混淆在一起导致架构层次混乱。

逻辑

逻辑的抽象复用可以说是所有软件开发活动中最为重要的一条原则,衡量一个程序员代码水平的重要原则之一就是看他代码中重复代码和相似代码的比例。大量重复代码或相似代码背后反映的是工程师思维的懒惰,因为他觉得复制粘贴或者直接照着抄是最省事的做法。这样做不仅看上去非常的丑陋,而且也非常容易出错,更不用提维护起来的难度。

数据中台

产品化是一种技术沉淀,从 CASE BY CASE 支持业务功能过程中,作抽象,把一些通用功能和模块独立出来,配合一些周边的技术工具和便利化的管理界面,形成产品化的结果,更高效的实现一种或多种业务需求,是技术效能提升的方法之一。产品化作得好的系统是一个闭封性优秀的系统,尽量不要外面的使用者关心我内部的实现。

模块化是把系统分离的一种设计思路,模块化后可以方便重复使用和插拨到不同的平台,不同的业务逻辑过程中。

产品化的系统一般都会在内部实现组件化,把模块独立抽象成组件,分离组件边界和责任,便于独立升级和维护。组件化可以让一个产品化的系统更可维护。

平台是一组程序的集合,提供了一系列的接口或界面。平台化是让一个系统具备装载很多不同外部系统的能力。平台化作得好的系统,要吧让外部系统很方便的了解你的内部能力,实现自由方便的插拨。平台化是一种对外的能力,提升的是外部系统与平台系统之间的联接能力,以开放作为设计目标,而不是封闭。

我们的系统有很多服务中心,会员中心,商品中心,产易中心和营销中心等。建这些中心的目的是为了业务系统解偶,为了让业务系统能更专注各自的业务逻辑,让通用业务下沉或平移抽出成为服务中心。中心化和组件化的不同一般是远程和本地的区别。以前客户端软件多用组件化设计,而互联网架构多用中心化,服务中心内部可以有不同的组件化设计,业务系统内部也常用组件化的设计。 中心化可以隔离易变和不易变的逻辑,也可以隔离不同运维策略的业务逻辑。中心化的系统一般符合职责单一原则,在面对对象设计的理论下,中心化可以看作一个逻辑上的大的对象来对待。服务中心是一个完整的业务闭包,可以完成一整组业务逻辑。 中心化不一定需要服务化。业务单元也可以中心化。

服务化,服务化一般是指远程调用的形式,我们关注调用的协议,API 和内容的格式。一个 API 可以独立服务化,一个服务中心也可以通过网关来实现服务化。 服务化有时候也用本地的二方库,类库包的形式提供服务。 服务化关注服务的治理策略和方法,手段。服务化关注服务注册,服务协调,服务可用性,服务通讯协议和内容交换。

SOA 是为了更好的集成,为了隔离不同逻辑之间的互相影响而形成的架构设计理念。服务化是 SOA 的一种实现方式。SPI 是一个接口标准规范,需要别人去实现;API 是标准的实现,可以直接使用。

架构师是一个既需要看全局整体又需要攻坚局部瓶颈并能在业务场景中平衡取舍方案的人,中台和前台,后台都需要架构师,架构师有自已的领域经验。

架构师是分领域的。架构师通过领域建模来划分业务边界,用领域经验来隔离变化,预测变化。很多系统的重复建设,与架架构的领域分拆不清楚有关系。可以借这个底层的实体关系模型来帮助系统建模,找到所有角色、实体对象和关系。 领域建模是一个抽象事实的过程。要为将来的业务扩展性和变化作好足够的准备。

中台和前台的区别是,前台实现业务逻辑和试错,需要比较多的人,这些人可能会失败。而中台实现通用逻辑和工具,产品,帮助前台快速试错,中台失败的可能性应该比较低,把可能错的事让前台去完成。中台人要少,前台人要多。如果前台人少,中台人多,那这个中台基本上应该归属到前台。中台的重点是产品化和平台化。中台应该是一系列能力的组合,包括组织规范和系统的规范,人和系统的一个方法论,标准。

诉求不是需求,而是需求的本质。电商业务中台由一系列业务能力标准、运行机制、业务分析方法论,配置管理和执行系统以及运营服务团队构成的体系,提供各业务方能够快速,低成本创新的能力。

定义能力的定义与标准,提供一个能力注册、发现、查询等管理的机制与管理系统;提供全局性的业务或应用注册管理中心,要让业务跑在大平台上,而不是一个或几个平台上。

提供一套或多套领域对象建模方法论或标准,比如按领域驱动设计 DDD;提供一系列成熟的案例或解决方案,提供多端化开发规范。

定义平台化的标准,定义可以实现平台化的框架的标准,比如框架需要提供模块化、流程化、插件、扩展等功能 。平台化的标准是什么?玄难大师有个很好的比喻,如果你的业务能一键上线或下线,就接近平台化了。这里的一键上下线,不是指单纯的切换一个开关,而是要做到部署的代码里不再有和该业务相关的任何代码。

平台化的基础构建,定义业务规则的定义,提供一个统一的业务规则平台(非中心,非动态编译引擎),支持自定义 DSL 插件,权限,审批流程等等,最终每个业务方都可形成自己业务领域的知识库。建设元数据管理中心,与业务规则等平台打通。提供一套服务鉴权的机制。可配置固然重要,但其重要性远低于平台化。

软件设计

软件设计有以下四大目标:简单、正确、一致、完整,但两大流派 MIT Style (MIT AI Lab 是 LISP 重镇) 和 New Jersey Style (C 和 UNIX 的老家贝尔实验室所在地) 对这些目标的优先级排序不同。MIT Style 认为软件正确性要绝对保证,然后优先级 正确 ~= 一致 > 完整 > 简单,简单这一条还得分,为了接口简单,可以忍受实现复杂。而 New Jersey Style 是正好反过来:首先软件实现得简单,做不到宁愿让接口复杂点,为了简单显然可以牺牲完整性,而正确、一致,那就尽力吧…… 反正得简单。Worse is Better 前面的 Worse 指的就是像 UNIX 这样为简单甚至能放弃「正确」这种有绝对标准的好的东西,后面的 Better, 指的是更好的生存适应性,这里面不带价值判断,文章作者也为 "Worse Is Better Is Worse" or "Worse is Better is Still Better" 一直在纠结,但这是一个能解释很多现象的准确观察。