专栏名称: 京东成都研究院
京东商城成都研究院信息平台
目录
相关文章推荐
成都发布  ·  热度攀升!绿道骑行火了,重要提醒→ ·  昨天  
成都发布  ·  年内开通!13号线一期华西坝站首次亮相 ·  昨天  
成都本地宝  ·  明日正式开通!成都天府机场高速出行更方便! ·  2 天前  
成都本地宝  ·  成都新生儿怎么线上申领社保卡? ·  4 天前  
51好读  ›  专栏  ›  京东成都研究院

如何防止软件系统的熵增

京东成都研究院  · 公众号  · 成都  · 2018-09-17 18:51

正文

1

1. 熵增的概念

1.1 什么是熵增

熵的概念最早起源于物理学,用于度量一个热力学系统的无序程度。热力学第二定律,又称“熵增定律”,表明了在自然过程中,一个孤立的系统总是从最初的集中、有序的排列状态,趋向于分散、混乱和无序;当熵达到最大时,系统就会处于一种静寂状态。

通俗的讲:系统的熵增过程,就是由原始到死亡的过程。(熵增定律同时也是一个哲学问题)。“熵”是“活跃”的反义词,代表负能量。

1.2 如何反熵增

反熵增,即熵减。是通过系统之外的第三者对其“做功”,实现对孤立系统的“熵转移”,使得原系统的熵总量减少;熵减可以使系统从混乱恢复有序。

2

2.软件系统的熵增

在软件开发、维护过程中。软件的生命力总是从最初的理想状态,逐步趋向于复杂、混乱和无序状态发展,直到软件不可维护而被迫下线或重构。这种损坏软件质量的因素的逐步增长,叫做软件的熵增现象。

2.1 软件熵增的表现

  1. 代码混乱、新人不易上手

  2. 代码高度冗余,复用性低,开发效率低

  3. 扩展和修改困难,牵一发动全身

  4. 业务数据错乱

  5. 程序性能低下

  6. 系统难以移置

  7. BUG率居高不下

  8. 其它……

2.2 软件熵增的导因

系统本身缺乏设计和规范的定义

  1. 开发人员太“个性”,不遵守设计和开发规范

  2. 开发人员不了解架构,随意更改和扩展

  3. Leader或架构师对代码的管控缺位

  4. 特殊或不合理的需求导致的架构妥协

  5. 赶进度时采用更快捷的“临时解决方案”

  6. 开发人员缺乏“重构精神”

  7. 开发团队重业务实现,不重设计。

  8. 其它……

3

3.软件系统反熵增

从前述的分析,我们现在基本可以明确,软件熵增的根本导因是:架构被忽视,或架构失控所导致。那么,如何进行软件系统反熵增? 答案是对软件架构做“功”。做“功”可以采取的措施如下:

3.1 认识软件架构

当在考虑软件架构时,首先需要明白任何软件系统都应该根据具体的应用和业务场景,而确立一种“架构风格”或“架构模式”。常见的系统架构模式有:

  1. 分层模式(Layer)

  2. 管道-过滤器模式(Channel Filter) = 流式(Stream)

  3. 主从模式(Master Slaves)

  4. 点对点模式 (P2P)

  5. 事件驱动模式 (EDA)

  6. MVC模式(MVC)

  7. ……

需要说明的是,在确立架构模式时,并非单选项,而是多选项。你可以根据需要将各种架构模式进行嵌套实施。而本次分享,主要是以最为常见,且应用最为广泛的“分层模式”为例来探讨。

3.1.1核心组成

3.1.2 分层

关于分层:

  1. 按问题域划分的逻辑或实体层次

  2. 每一层都有清晰的边界

  3. 越上层越简单,越底层越复杂

  4. 上层面向用户,底层面向机器

  5. 分层间自顶向下依赖

  6. 上层依赖底层是调用,底层依赖上层是通知

  7. 每一层可单独测试、复用和交付

常见的分层级别有两种:应用服务级 、系统架构级。其中,应用服务级指的是单个进程内部的代码分层。而系统架构级则是整体架构分层,比前者的视野更高。

3.1.3 模块

关于模块:

  1. 按业务或职能域划分的逻辑或实体模块

  2. 模块归属于特定的分层,是分层的组成单元

  3. 每一个模块都有清晰的边界

  4. 模块的边界取决于领域模型

  5. 模块是对领域模型的具体实现

  6. 上层模块依赖下层模块,同层模块间最小依赖

3.1.4 组件

关于组件:

  1. 组件,概念等同于library

  2. 组件与模块的特性相似

  3. 组件的粒度小于模块

  4. 组件可被包含于模块内部,也可以独立。

  5. 模块内部组件是私有组件,独立组件是公共组件。

  6. 组件的交付形态可以是: 类、JAR包、OSGI Bundle、Maven Module、Plugin等。

3.1.5 领域模型

关于领域模型:

  1. 领域模型,也称概念模型,是软件系统的核心业务模型。

  2. 领域模型描述的是系统的各个业务实体,以及实体间的关系。

  3. 领域模型是进行系统架构和模块设计的基础和依据。

  4. 架构设计的第一步,就是对领域进行建模。

  5. 领域模型的演进,是随着产品需求变化一起迭代。

  6. 领域模型设计得越稳定,系统风险越低。

  7. 我们所熟悉的E-R图,就是领域模型的一种表现形式。

3.1.6 外部对象

外部对象,是指当前软件系统以外的,被当前系统所依赖和引用的外部系统或服务。例如工作流(BPM)、统一权限服务、敏感词检测服务(OCR)等等。通过引用外部服务来完成当前软件系统所需要的特定的功能或者业务。

3.1.7 中间件

关于中间件:

  1. 中间件是构建业务系统的必需品

  2. 中间件组成系统的基础架构

  3. 中间件与业务无关,仅提供公共的技术服务

  4. 中间件是系统技术选型的结果

  5. 原则上,系统任意层均可直接依赖中间件

  6. 其它……

中间件和外部对象,都属于当前软件系统之外的对象。但他们区别在于:中间件是基础,是必须品,他与软件的技术架构有关。而外部对象则与业务有关,但不一定是必须品。

3.2 做好架构设计

在软件设计阶段,需要对软件架构做好概要设计。一般地,需要做以下工作:

  1. 领域分析与建模







请到「今天看啥」查看全文