读架构漫谈感悟
架构漫谈-阅读笔记
架构漫谈一
什么是架构:
通过阅读架构漫谈这几篇文章,我对架构这个名词有了初步的认识。架构,顾名思义,就是结构,正如文中所介绍的那样原始社会有了分工,并且通过交易使每个个体获得生活的必需品,这样就构成了社会的架构。那么架构的准确定义就是:把一个整体切分成不同的部分,由不同角色来完成这些分工,并通过建立不同部分相互沟通的机制,使得这些部分能够有机的结合为一个整体,并完成这个整体所需要的所有活动,这就是架构。
架构官方的定义就是:
- 根据要解决的问题,对目标系统的边界进行界定。
- 并对目标系统按某个原则的进行切分。切分的原则,要便于不同的角色,对切 分出来的部分,并行或串行开展工作,一般并行才能减少时间。
- 并对这些切分出来的部分,设立沟通机制。
- 根据 3,使得这些部分之间能够进行有机的联系,合并组装成为一个整体,完成目标系统的所有工作。
架构漫谈二
根据架构的定义,要做好架构所首先必须具备的能力,就是能够正确的认识概念,能够发现概念背后所代表的问题,进而才能够认识目标领域所需要解决的问题,这样才能够为做好架构打好基础。事实上,这一能力,在任何一个领域都是适用的,比如我们如果想要学习一项新的技术,如 Hibernate、Spring、PhotoShop、WWW、Internet 等等,如果知道这些概念所要解决的问题,学习这些新的技术或者概念就会如虎添翼,快速的入手;学习一个新的领域,也会非常的快速有效;使用这些概念来解释问题,甚至发明新的概念都是很容易的事。为什么强调这个呢,因为做架构的时候,很多时候都是在一个新的领域解决问题,必须要快速进入并掌握这个领域,然后才能够正确的解决问题。
架构漫谈三
按照之前架构的定义,做好架构首先需要做的就是识别出需要解决的问题。一般来说,如果把真正的问题找到,那么问题就已经解决80%了。这个能力基本上就决定了架构师的水平。
那么面对问题有哪些困难呢?
我们先看一则笑话。女主人公:老公,把袋子里的土豆切一半下锅。结果老公是把袋子里的每个土豆都削了一半,然后下锅。
当然很多人会说,这个是沟通问题,然后一笑了之。其实,出现这个现象是由于我们大部分时候过于关注解决问题,急于完成自己的工作,而不关心“真正的问题是什么”而造成的。当我们去解决一个问题的时候,一定要先把问题搞清楚。这也是我为什么要单独写一篇文章讲这个的原因。去看看软件开发工作者的时间分配也可以看出,大家大部分时间花在讨论解决方案和实现的细节上,基本都不会花时间去想“问题是什么”。或者即使想了一点点,也是一闪而过,凭自己的直觉下判断。只有真正投入思考问题是什么的工程师,才可能会真正的成长为架构师
以这个笑话为例,看看在我们处理问题的时候,都会犯什么样的错误:
- 被告知要处理一个问题,但是交过来的实际上是一个解决方案,不是问题本身。
- 被告知要处理一个问题,直接通过直觉就有了一个解决方案,马上考虑解决方案如何落地,或者有几种解决方案,选哪个合适。
总结一下,要正确的认识问题,需要问两个问题:
- 这是谁的问题?
- 有什么问题?
当得到的回答是支支吾吾的时候,我们就知道正确的方向在哪儿,以及需要做哪些事了。以我的经验,问题1会花比较多的时间,也是支支吾吾最多的地方,因为架构要解决的问题都是人的问题。但是一旦确定了答案,问题2就会变得非常容易。可以这样说,架构师的能力大部分会体现在问题1的识别上。
架构漫谈四
为什么需要切分?
当人们认识到要主动的去切分一个系统的时候,毫无疑问,我们不能忘掉利益这个原动力。所有的切分决策都不能够违背这一点,这是大方向。结合前一篇“识别问题”,一旦确定了问题的主体,那么系统的利益相关人(用现代管理学语言叫:stakeholder)就确定了下来。所发现的问题,会有几种情况:
- 某个或者某些利益相关人负载太重。
- 时间上的负载太重。
- 空间上的负载太重,本质上还是时间上的负载太重。
- 某个或者某些利益相关人的权利和义务不对等。
总结一下
- 架构的切分是解决现实问题的通用办法,即‘分治’思想。
- 架构的切分实际就是对stakeholder的利益进行切分或合并,使得每个stakeholder的权责是对等的,每个stakeholder可以为自己的利益负责。
- 架构切分的最终结果都会体现在组织架构上,只有这样才能够让架构落地并推进。
架构漫谈(五)
什么是软件?
官方的定义是:一系列按照特定顺序组织的计算机数据和指令的集合。一般来讲软件被划分为系统软件、应用软件和介于这两者之间的中间件。软件并不只是包括可以在计算机(这里的计算机是指广义的计算机)上运行的电脑程序,与这些电脑程序相关的文档一般也被认为是软件的一部分。简单的说软件就是程序加文档的集合体。另也泛指社会结构中的管理系统、思想意识形态、思想政治觉悟、法律法规等等。
架构漫谈(六)
软件架构到底是要解决什么问题?
业务问题的本质,是业务所服务的对象的利益问题,明白了这个,就很容易搞清业务的概念和组织方式。再次强调一下,有了软件,可以降低业务的成本,没有软件的情况下,业务是一样跑的。如果只是为了跟风要用软件,说不定反而提高了成本,这个是采用软件之前首先要先搞清楚的。我们经常说软件和技术是业务的enabler,实际就是把原来成本很高的降到到了很低的程度而已,并不是有了什么新的业务。另外,软件也不是降低业务成本的唯一方式。
为了能够让软件很好的跑起来,软件工程师必须理解业务所服务的对象,他们的利益所在,即业务问题。业务面对这些问题是如何分拆解决的? 涉及到了哪些概念? 这些概念分别解决了哪些哪些问题? 我们不能自己按照自己的理解,用自己的一套概念体系来表述。如果这么做的话,会导致两个问题:
1)业务无法和我们交流,因为他们无法明白我们所自己创建的概念,所以他们无法确认我们的理解是否正确。
2)我们所表述的东西,并没有在实际生活中实践过,我们也不知道这些概念是否能够解决业务的问题。
软件工程师还必须要考虑,用什么样的硬件把软件跑起来,怎样跑得好,跑得快,并且可以随着业务的流量逐渐的长大?
架构漫谈(七)
不要空设架构师这个职位,给他实权。
什么是架构师:
很多人会问,特别是做软件行业的,架构师是不是需要学习技术,甚至是学习语言? 如果一个架构师还有这个困扰——就如问这个问题的人,说明目前还不具备做架构师的能力,或者说还不具备对自己领域——哪怕是技术领域——的自信,更别谈业务领域了。
因为技术和语言,都是用来识别和解决所服务的主体的权责,保护并提升所服务的主体的权利的。特别对于软件领域来说,必须明白软件本身是怎么回事,解决什么问题,还要解决软件所服务的对象的领域本身是怎么回事,解决什么问题,这就要求更高了。语言和技术应该是随手拈来才对,对于架构师这些都是工具。学习技术和语言,如果明白了这些技术和语言要解决的是谁的问题,什么问题,学起来是非常快,非常容易的。
同样,采用哪个技术或者语言,只要某个技术或语言所解决的问题的主体,以及所解决的问题,和自己所面对的问题的主体和这个主体要解决的问题,这两者是匹配的,那么这个方案的成本是最低的,所采用的技术或者语言就是靠谱的。没有趁手的工具或语言的情况下,自己设计一个也不难,因为很清楚自己要什么。要不要自己做,无非是一个成本问题,也就是利益问题。并且从这个思路下去,选择的工具和语言肯定都是最简单的,成本是最低的。因为架构毕竟解决的还是人的利益问题,成本越低越好,这个成本当然是长期总体成本,不是眼前的短期成本。
posted on 2019-03-24 21:28 xiaohaigege666 阅读(167) 评论(0) 编辑 收藏 举报