软件架构师如何工作-架构漫谈阅读笔记

Posted 卡卡罗特

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了软件架构师如何工作-架构漫谈阅读笔记相关的知识,希望对你有一定的参考价值。

  在王概凯先生的9篇关于软件架构师的博客-《架构漫谈》中,我们可以看到文中谈到了架构的定义、含义,架构主要是要认识概念,如何做好架构之架构的切分,然后谈到了软件与架构之间的关系(什么是软件,软件架构是要解决什么问题,从架构的角度看如何写好代码,理清技术、业务和架构之间的关系了),下面依次写出我对9篇博客的理解与感悟,以及对软件架构师工作的理解。

  一:什么是架构

    在学习软件体系结构这门课之前,我们貌似只对软件开发以及简单的mis系统的开发有一丝丝的开发经验和感触,无架构之言。我们目前还无法像软件架构师那样去思考问题。在第一篇博客中,王先生给出了架构的基本定义-Architecture (Latin architectura, from the Greek ?ρχιτ?κτων arkhitekton”architect”, from ?ρχι- “chief” and τ?κτων “builder”) is both the process and the product of planning, designing, and constructing buildings and other physical structures。(从这个定义上看,架构好像是一个过程,也不是很清晰。为了讲清楚这个问题,我们先来看看为什么会产生架构)。

      在每个人都必须自己完成所有生活必须品的生产的时候,是没有架构的(当然在个人来讲,同一时刻只能做有限的事情,在时间上还是可能会产生架构的)。一旦产生的分工,就把所有的事情,切分成由不同角色的人来完成,最后再通过交易,使得每个个体都拥有生活必须品,而不需要每个个体做所有的事情,只需要每个个体做好自己擅长的事情,并具备一定的交易能力即可。

  当然,最后王概凯给出了架构的概念,即:根据要解决的问题,对目标系统的边界进行界定。所以,一个合格的软件架构师,需要以一种类似与结构设计是来看待问题、分析问题,提出问题的解决方案。

  二:认识架构是理解架构的基础

    在“概念”这个含义中,很多人都有认识的误区,下面,我就介绍一下文中作者给我们举出的例子:大部分人对于每天都习以为常的概念,都自以为明白了,但实际上都是下意识的,并不是主动的认识。比如说“什么是桌子?”,做培训的时候,我经常拿这个例子来问大家,回答千奇百怪。这实际上就导致了做架构的时候,不同角色的沟通会出很多问题,那么结果也就可想而知了。

    如前一篇所说,架构实际上解决的是人的问题,而概念是人认识这个世界的基础,自然概念的认识就非常的重要。这篇文章尝试讨论一下,如何去认识概念。当然这篇不是语言学的文章,我这里所讨论的,和语言学可能不太一样,如果大家对语言学感兴趣,也可以去参考一下。

    文中,王先生提出了中国古代传统文化关于“概念”的研究与探索。原文不在这里赘述,大致意思是这样的:在中国的古代,“概念”一词的含义用另外一个词来表示,即“名相”。相-即能看到的东西,当听到完整的名词,脑子里想到的实物(包括他的形状、用处等)叫做-名,加一起就是名相。但是,如果这个物体性状发生改变,我们对它的感觉也会发生改变。比如说,一个杯子,打碎了,便是一堆碎瓦片。如果磨成粉,那就是一堆没用的齑粉。那究竟什么才是相?实际上“相“表达的不是一个具体的东西,如上面所提的一个瓷器杯子,并不是指这个瓷器,而是这个瓷器所起的一个作用:一手可握,敞口(一般不超过底的大小,太大口就叫碗了),并且内部有一个空间可乘东西的这么一个作用。并不是指这个瓷器本身。这也是为什么我们从电视上看到一个人拿杯子的时候,我们知道这个是杯子。但是实际上我们看到的都是光影而已。所以说相实际上代表的是这个作用,并不是具体的某个东西,而名是用来标识这个作用的,用来交流的。

    回过头来,根据架构的定义,要做好架构所首先必须具备的能力,就是能够正确的认识概念,能够发现概念背后所代表的问题,进而才能够认识目标领域所需要解决的问题,这样才能够为做好架构打好基础。事实上,这一能力,在任何一个领域都是适用的,比如我们如果想要学习一项新的技术,如Hibernate、Spring、PhotoShop、WWW、Internet等等,如果知道这些概念所要解决的问题,学习这些新的技术或者概念就会如虎添翼,快速的入手;学习一个新的领域,也会非常的快速有效;使用这些概念来解释问题,甚至发明新的概念都是很容易的事。

  三:如何做好架构之识别问题

    按照之前架构的定义,做好架构首先需要做的就是识别出需要解决的问题。一般来说,如果把真正的问题找到,那么问题就已经解决了80%了。这个能力基本上就决定了架构师的水平。可是,当我们面对问题是,有哪些困难呢?原文中的一则笑话,可以说明形象的表达困难在哪。女主人公:老公,把袋子里的土豆切一半下锅。结果老公是把袋子里的每个土豆都削了一半,然后下锅。被告知要处理一个问题,但是交过来的实际上是一个解决方案,不是问题本身。被告知要处理一个问题,直接通过直觉就有了一个解决方案,马上考虑解决方案如何落地,或者有几种解决方案,选哪个合适。作为软件工程师或者架构师,我们大部分时候是要去解决别人的问题,“别人”是谁,是值得好好思考的。在这个故事里面,男主人要解决的,实际上是这个家庭晚餐需要吃土豆的问题,目标问题的主体实际上是这个家庭的成员。这里,我们得到了一个结论,即软件架构师应该考虑问题的本质,用户真正需要的,而不是按照自己的解决方法,敷衍的解决问题,这里好像是数学中的大题。如果有一道很复杂的函数问题,给人直观的感觉是可以用各种式子推到出来。可这是出题人的原想法吗?细心点我们可以发现,原来这道问题可以用一个定理推导得出。所以,解决问题,我们要学会找出提这个问题的人的真正需求,而不能简单的按照自己的解决思路生搬硬套。

    

    

 

以上是关于软件架构师如何工作-架构漫谈阅读笔记的主要内容,如果未能解决你的问题,请参考以下文章

软件架构师如何工作

《架构漫谈》阅读笔记

[架构漫谈]软件架构师如何工作

架构漫谈有感之软件架构师如何工作

《架构漫谈》阅读笔记

软件架构师如何工作