轻架构(一):缘起--架构的核心目标是什么

 

 

 在现在这个时代,架构变得异常复杂,也异常艰深。轻架构这个概念,也就是让架构正本清源,回归本来面目。那什么是架构的本来面目呢?

 

架构的英文是Architecture,本身是一个从建筑行业学习来的词语,用在软件设计和开发这个领域,主要是指“系统在其环境中的最高层概念”(IEEE98),架构的任务指:建造一个系统所作出的最高层次的、以后难以更改的,商业的和技术的决定。这样的决定是有关系统设计成败的最重要决定,必须经过非常慎重的研究和考察。

 

         用一个人类社会的事情来比喻,当然,我们也常常说到,一个公司的“组织架构”,例如我们建立了一整套从总经理、副总到部门经理、助理和普通职员的组织关系,建立了这些关系之间工作指派、工作汇报和工作总结的机制;我们把公司划分为几个不同的部门 分工协作,各个部门完成自己的工作目标,从而完成正规公司的目标。

 

         上面这段话其实体现了架构的几个基本点,第一是分层以及层次之间的关系;第二是分模块以及模块之间的关系,第三个基本点是划分好各个层次、各个模块的职责。各个模块、层次各司其职,系统良好运转,架构的作用隐含于其中。人们看得见各个层次和模块,倒是忘记了这个架构本身

 

         在上面的类比中,我们可以看到。其实公司的目标,都是各个层次、各个部门来完成的,但是却没有任何实际问题是由架构本身来解决的,架构本身没有提供任何“真正”的价值,但是架构却又是最最关键的,一个不好的架构,使各个层次、各个部门之间相互掣肘,内耗严重,效率极差,解决什么问题也困难,达到总体目标就很难。

 

再来看软件架构,与上面的公司架构一致,它要完成一个系统的复杂度切分,架构本身不解决系统的任何问题,只是把系统的复杂度切分到不同的子系统或模块或层次中中。架构关心的是系统整体的耦合度。模块切分时的平衡、复杂度切分时是否合理。

 

之所以在这个时候提出这个概念,是因为架构这个词被用得太泛滥。架构这个概念包含了太多的内容,以至于架构师成为设计开发过程最累的角色,负担了太多太多的东西。而且,因为事情太多太杂,导致根本性的任务做的不好,今儿严重影响产品质量,产品常常变成大杂烩。所以,有必要正本清源,把纯粹架构的内容抽离出来说。

 

抽离出来之后,架构本身应该不解决任何问题域的问题,只是使问题域的每一个问题都更容易找到解决者。或者为每个问题,提供了一个寻找解决者的途径和方法,尽可能使问题都能更快速、更顺畅的找到解决者。架构为一个组织(一个软件)内部的控制传递、数据传递提供了好的通道和路线,但本身不发送任何控制和数据。

 

例如,设计房子画出了设计图,但是画图的设计师不卖建筑材料,不卖建筑工具。在一个公司内部,组织部门的人并不解决客户的问题。

 

轻架构的目标:

         (显式)

     系统层次和模块划分

         系统层次之间和模块之间的关系和通信

         维护概念完整性和一致性

         (隐式)

         架构复杂度的评估、模块复杂度的评估

         后续设计的规范

         技术选型、技术路线的选择

        

 

纯粹架构对系统后续的设计和开发的重要性是不言而喻的,这并不是说其它部分不重要。架构的重要,在于在切分系统时,维护概念完整性和概念一致性;大体上平衡的分配系统的复杂度和工作强度,使系统能够顺畅的进行设计和开发。

最最关键的是,把所谓模块的高内聚低耦合、最大限度设计和代码重用、用哪些设计模式、采用SSH还是SSI、Tomcat还是Jetty、设计共用(通用)组件内容从架构中剥离出去。不是说 不重要,而是这些与架构无关。

 

这样来做的话,架构似乎变得容易了,很多人都会这么看,其实不是这样的。这样来拆分,其实是希望架构师能够真正的处理好本职的工作。

 

架构师的本职工作是什么?有人说“设计高质量的产品”,这句话太通用,因为这是产品设计和开发的根本目标,也是团队的整体目标。而架构师在过程中所承担的最重要的任务,其一是维护产品的概念完整性和一致性。产品一个版本一个版本的前进,新特性不断加入,不断吸收新的需求,纳入新的概念,在这个过程中,保持产品始终围绕着一个或一组概念(否则产品会被演变成拼盘和大杂烩,变成一种技术元素的堆砌),实在不容易。因为这个是产品的长远利益,所以在以短平快为目标的团队中直接被无视,固然有一种无奈,但毕竟不是一种好的选择。

其二是分层和模块划分,这个会从根本上影响系统的可扩展性、可生长性,而之后的模块设计和代码,对可扩展性和可生长性的影响是很小的。当然,效率、安全性等非功能特性,都是应该在分层、分模块时要慎重和仔细考虑的。

 

这两个本职工作,其实也就是软件产品的设计开发过程中,最最核心价值的所在,最最本质的点,最最需要付出艰苦的脑力劳动的地方。是设计开发活动中最最需要花心思花时间和精力的关键点,关键中的关键。正是因为架构师很多都是百炼成钢,经验丰富,才会担当这样的重任。

 

         反过来想,为什么现代软件开发过程会被比喻成“焦油坑”?为什么设计行业内架构这个职位这么不好做?我觉得现在设计开发过程中,架构师的职位定义是含糊不清的。从人上,救火队员,项目经理、老兵等等;从事情上,开发底层接口、编写设计文档或伪码、到客户处沟通需求这些是架构师的工作职责。很少有人意识到上边提到的架构师的根本职责、本职工作。因为这个认识不到位,所以使架构师没有把“架构”这件事做好,带来的问题就是产品质量低下,可扩展、可延续、可生长特性非常差,人力资源浪费,高投入低回报。

 

        

猜你喜欢

转载自windshome.iteye.com/blog/1933021