读架构漫谈感悟

架构漫谈-阅读笔记

  架构漫谈一

     什么是架构：

       通过阅读架构漫谈这几篇文章，我对架构这个名词有了初步的认识。架构，顾名思义，就是结构，正如文中所介绍的那样原始社会有了分工，并且通过交易使每个个体获得生活的必需品，这样就构成了社会的架构。那么架构的准确定义就是：把一个整体切分成不同的部分，由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，这就是架构。

    架构官方的定义就是：

1. 根据要解决的问题，对目标系统的边界进行界定。
2. 并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切 分出来的部分，并行或串行开展工作，一般并行才能减少时间。
3. 并对这些切分出来的部分，设立沟通机制。
4. 根据 3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。

  架构漫谈二

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

架构漫谈三

按照之前架构的定义，做好架构首先需要做的就是识别出需要解决的问题。一般来说，如果把真正的问题找到，那么问题就已经解决80%了。这个能力基本上就决定了架构师的水平。

那么面对问题有哪些困难呢?

我们先看一则笑话。女主人公：老公，把袋子里的土豆切一半下锅。结果老公是把袋子里的每个土豆都削了一半，然后下锅。

　　当然很多人会说，这个是沟通问题，然后一笑了之。其实，出现这个现象是由于我们大部分时候过于关注解决问题，急于完成自己的工作，而不关心“真正的问题是什么”而造成的。当我们去解决一个问题的时候，一定要先把问题搞清楚。这也是我为什么要单独写一篇文章讲这个的原因。去看看软件开发工作者的时间分配也可以看出，大家大部分时间花在讨论解决方案和实现的细节上，基本都不会花时间去想“问题是什么”。或者即使想了一点点，也是一闪而过，凭自己的直觉下判断。只有真正投入思考问题是什么的工程师，才可能会真正的成长为架构师

　　以这个笑话为例，看看在我们处理问题的时候，都会犯什么样的错误：

1. 被告知要处理一个问题，但是交过来的实际上是一个解决方案，不是问题本身。
2. 被告知要处理一个问题，直接通过直觉就有了一个解决方案，马上考虑解决方案如何落地，或者有几种解决方案，选哪个合适。

总结一下，要正确的认识问题，需要问两个问题：

1. 这是谁的问题？
2. 有什么问题？

　　当得到的回答是支支吾吾的时候，我们就知道正确的方向在哪儿，以及需要做哪些事了。以我的经验，问题1会花比较多的时间，也是支支吾吾最多的地方，因为架构要解决的问题都是人的问题。但是一旦确定了答案，问题2就会变得非常容易。可以这样说，架构师的能力大部分会体现在问题1的识别上。

架构漫谈四

为什么需要切分？

　　当人们认识到要主动的去切分一个系统的时候，毫无疑问，我们不能忘掉利益这个原动力。所有的切分决策都不能够违背这一点，这是大方向。结合前一篇“识别问题”，一旦确定了问题的主体，那么系统的利益相关人（用现代管理学语言叫：stakeholder）就确定了下来。所发现的问题，会有几种情况：

1. 某个或者某些利益相关人负载太重。
2. 时间上的负载太重。
3. 空间上的负载太重，本质上还是时间上的负载太重。
4. 某个或者某些利益相关人的权利和义务不对等。

　总结一下

1. 架构的切分是解决现实问题的通用办法，即‘分治’思想。
2. 架构的切分实际就是对stakeholder的利益进行切分或合并，使得每个stakeholder的权责是对等的，每个stakeholder可以为自己的利益负责。
3. 架构切分的最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进。

架构漫谈（五）

什么是软件？

官方的定义是：一系列按照特定顺序组织的计算机数据和指令的集合。一般来讲软件被划分为系统软件、应用软件和介于这两者之间的中间件。软件并不只是包括可以在计算机(这里的计算机是指广义的计算机)上运行的电脑程序，与这些电脑程序相关的文档一般也被认为是软件的一部分。简单的说软件就是程序加文档的集合体。另也泛指社会结构中的管理系统、思想意识形态、思想政治觉悟、法律法规等等。

架构漫谈（六）

软件架构到底是要解决什么问题？

业务问题的本质，是业务所服务的对象的利益问题，明白了这个，就很容易搞清业务的概念和组织方式。再次强调一下，有了软件，可以降低业务的成本，没有软件的情况下，业务是一样跑的。如果只是为了跟风要用软件，说不定反而提高了成本，这个是采用软件之前首先要先搞清楚的。我们经常说软件和技术是业务的enabler，实际就是把原来成本很高的降到到了很低的程度而已，并不是有了什么新的业务。另外，软件也不是降低业务成本的唯一方式。

为了能够让软件很好的跑起来，软件工程师必须理解业务所服务的对象，他们的利益所在，即业务问题。业务面对这些问题是如何分拆解决的？ 涉及到了哪些概念？ 这些概念分别解决了哪些哪些问题？ 我们不能自己按照自己的理解，用自己的一套概念体系来表述。如果这么做的话，会导致两个问题：
1）业务无法和我们交流，因为他们无法明白我们所自己创建的概念，所以他们无法确认我们的理解是否正确。
2）我们所表述的东西，并没有在实际生活中实践过，我们也不知道这些概念是否能够解决业务的问题。

软件工程师还必须要考虑，用什么样的硬件把软件跑起来，怎样跑得好，跑得快，并且可以随着业务的流量逐渐的长大？

架构漫谈（七）

不要空设架构师这个职位，给他实权。

　什么是架构师：

很多人会问，特别是做软件行业的，架构师是不是需要学习技术，甚至是学习语言？ 如果一个架构师还有这个困扰——就如问这个问题的人，说明目前还不具备做架构师的能力，或者说还不具备对自己领域——哪怕是技术领域——的自信，更别谈业务领域了。

　　因为技术和语言，都是用来识别和解决所服务的主体的权责，保护并提升所服务的主体的权利的。特别对于软件领域来说，必须明白软件本身是怎么回事，解决什么问题，还要解决软件所服务的对象的领域本身是怎么回事，解决什么问题，这就要求更高了。语言和技术应该是随手拈来才对，对于架构师这些都是工具。学习技术和语言，如果明白了这些技术和语言要解决的是谁的问题，什么问题，学起来是非常快，非常容易的。

　　同样，采用哪个技术或者语言，只要某个技术或语言所解决的问题的主体，以及所解决的问题，和自己所面对的问题的主体和这个主体要解决的问题，这两者是匹配的，那么这个方案的成本是最低的，所采用的技术或者语言就是靠谱的。没有趁手的工具或语言的情况下，自己设计一个也不难，因为很清楚自己要什么。要不要自己做，无非是一个成本问题，也就是利益问题。并且从这个思路下去，选择的工具和语言肯定都是最简单的，成本是最低的。因为架构毕竟解决的还是人的利益问题，成本越低越好，这个成本当然是长期总体成本，不是眼前的短期成本。