软件架构杂谈

在前两篇博客中介绍了android项目工程中的架构实施,但是却没有叙述为什么要做架构以及何时该做软件架构,于我而言确实有考虑不周的地方,因此趁周末时间把这篇文章补上,希望同学们能够谅解。

何为软件架构

在有些软件工程师眼中,软件架构是高深莫测的,甚至是遥不可及的,其实不然,她在我们开发生活中处处可见,可能产品需求过于混沌而导致你无暇看清她长什么模样,那今天就由我给同学们重新介绍一下她一一软件架构。在软件行业,人们对软件架构的定义可谓众所纷纭,毕竟一千个人眼中有一千个哈姆雷特,其中被普遍接受的定义是,计算系统的软件架构是解释该系统所需的结构体的集合,其中包括:软件元素、元素之间的相互关系,以及二者各自的属性。该定义罗列了软件架构至关重要的几个要素:元素、关系及属性。然而, 并不能简单地认为就是这些结构体组成了架构,而是说架构是解释系统所需的结构体的集合。"Hey , wait 你刚才不是说软件架构在开发中处处可见么,那些元素、关系以及属性还有什么xx集合,我怎么越听越糊涂了" 呃 ,别急,待我一一道来。众所周知,架构关注于设计的宏观部分,既然这么说,抽象肯定是必不可少的,要不怎么叫宏观设计呢,就如人体结构一样,把用来拿东西的部位称作手,把用来吃饭的部位称作嘴,手可以把饭拿到嘴边,人们把这些定义成组成身体的元素,还有它们之间的协同关系及各自的状态表征称作人体系统。软件系统亦如此,因此说软件架构是解释系统所需的结构体的集合就更合适不过了。

架构的必要性

知道如何实施软件架构和知道为什么要实施软件架构同样重要,难道不是么?如果你认为产品业务才是软件系统的核心,其它都是次要的,这样理解也不为过,因为无论产品经理还是软件工程师都最终为产品负责,把产品放在首位是毋容置疑的,但是软件架构也是产品能否成功的核心因素,它是根据软件功能设计而成,它是一个系统的骨架,决定着软件产品的质量属性,如果产品质量都堪忧那何谈把产品做好呢,可想而知,软件架构在软件工程中的地位是无法取代的,软件缺乏合理的架构一般会导致程序过度耦合、容易被破坏、难以应对变化,同时很难有一个清晰的版本或者方向性。这样的结果是,如果你没有充分理解软件系统里每个组件和模块,就很难定义这个软件的模块特征,软件架构的重要性在于它会影响整个软件系统。只有谨慎地选择软件架构,才能降低风险,避免失败。

何时开始架构

知道什么是软件架构后,那何时去实施软件架构工作呢,有人会说在设计先行,这类人会把架构看的至关重要,在一个完善的架构落定之前就不会动手写业务实现,也有的人会说软件架构不必刻意去追求,它会随软件工程发展而自然呈现。世间本无对错之分,只是人的主观思想罢了,所以不必为别人不同意自己的观点而恼怒,自己认为是对的,坚持下去就好。针对何时去做软件架构我也有自己的理解,对于一个特定的项目工程,我们首先要做的事就是项目评估,评估的层面有很多,比如人力、财力以及收益等,如同不打无把握的仗,我们不会实施没有收益保障的工程,毕竟我们是一个团队,谁都不愿意做没有意义的事。

功能导向架构

都说脱离软件功能的架构设计就是在耍流氓,其实不然,软件系统的架构选择本应与软件功能相互独立的,但是全然不顾软件功能就确定架构决策却是不可取的,一个错误的软件架构决策势必会给软件功能以及软件质量目标的实现带来不可预知的障碍,在没有了解项目工程所需的业务功能之前就落定软件架构抉择是不明智的选择,一旦架构选择的不合适,开发者就是举步维艰,所以在我们选择架构时一定要慎重。

架构与详细设计

在有些团队经常会在架构设计和详细设计间徘徊,对架构设计和详细设计没有清晰的概念,在进行详细设计时可能就影响到架构决策,是否设计细节未满足架构约束还是目前架构并不完善而阻塞了详细设计实施,那这些细节就该上升到架构层面,可以这么理解判断设计细节是否属于架构范畴,就是看这些细节是否会直接影响软件的整体质量。

何时中止架构

在软件工程的生命周期中我们不可能一直在做架构工作,何时中止架构工作转而进行详细设计呢?如果当前架构可以满足项目既定目标就可以中止架构工作了,但是这也是有些不妥的,我们必须要对未来项目风险进行分析、评估,假如风险在可控的范围内,可以达到预期的软件质量目标,那我们就可以暂时停下架构工作进行详细功能设计了,假如风险影响到软件质量,那我们就不能草率进行详细设计了,我们绝不能低估未来的工程风险,要知道有些风险是致命的,可以直接导致工程走向失败,所以只要项目风险在可控范围之外那我们就不能中止架构工作。

分层架构实战

分层架构被认为是所有架构模式中最简单的,该模式里的组件被分成几个平行的层次,每一层都代表了应用的一个功能特性。分层架构在多数情况下会被分成四个层次:展示层、业务层、持久层、和数据库层。其组织关系如下图:

分层架构中的每一层都着特定的角色和职能,比如展示层负责处理所有的界面展示以及交互逻辑,业务层负责处理业务逻辑。架构里的层次是具体工作的高度抽象,它们都是为了实现某种特定的业务请求。比如说展示层并不需要关心怎样得到用户据,它只需在屏幕上以特定的格式展示信息。业务层并不关心要展示在屏幕上的用户数据格式,也不关心这些用户数据从哪里来。它只需要从持久层得到数据,执行与数据有关的相应业务逻辑,然后把这些信息传递给展示层。分层架构的一个突出特性是组件间关注点分离 ,一个层中的组件只会处理本层的逻辑。比如说,展示层的组件只会处理展示逻辑,业务层中的组件只会去处理业务逻辑。

结语

关于软件架构岂是一篇文章就能讲的清楚的,她还需要大量的项目工程实践,毕竟她本身就是一门艺术,只有经过多少个日落的品味才能对她产生感觉,所以本文只是个点播,内容稍显空洞,读完能有个概念就行。

admin

发表评论

电子邮件地址不会被公开。 必填项已用*标注