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

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