首页 > 其他分享 >读《架构漫谈》有感

读《架构漫谈》有感

时间:2024-02-28 20:44:09浏览次数:14  
标签:架构 有感 不同 漫谈 问题 切分 利益 架构师

今天课堂上老师带大家阅读了《架构漫谈》,并且给大家提出了一系列的问题,以下是问题以及我的理解

  1. 什么是架构:

明确需要做的全部工作,即界定边界;并且将全部工作进行合理划分,使不同的生产力完成不同的工作,使其可以节约成本,提高生产效率

  1. 为什么要出现架构:

不同的生产力有不同的分工

架构可以使不同分工的生产力可以充分利用,从而提高生产效率

  1. 架构解决谁的问题:

解决群体的问题,群体有不同的分工

作者通过一个人群的分工配合的例子引出了他对架构的一个定义:把一个整体(完成人类生存的所有工作)切分成不同的部分(分工),由不同角色来完成这些分工,并通过建立不同部分相互沟通的机制,使得这些部分能够有机的结合为一个整体,并完成这个整体所需要的所有活动。再总结一下,架构是一个有不同部分构成的一个整体,且不同部分之间是相互联系的。架构是由人类自身的缺陷和出于目的而产生的。人类自身的能力和专注力有限,而想要的目标却往往是一个人不能达到的,于是不同的个体联系成一个整体,通过个体之间的协调和沟通而达到一个共同的目的,使得整体的存在有明确的意义。

       如何做好架构呢?切分,我们要对整个项目需求进行切分,还要把控对于利益的调整。一旦确认问题的主体,我们接下来会发现如下问题,某个或者某些利益相关人负载太重,或者时间上空间上负载太重,或者某个,某些利益相关人的权利和义务不对等。所以我们需要在一定原则上进行切分,第一是自然就无法切分的部分,第二是不违反人性。随后就是一系列建模和组织架构了。成为架构师的前提条件、如何发现“是谁的问题”、架构师的权利和义务等话题。正如作者所说,架构师必须是一个组织的领导人,有权利调动这个组织的架构,才能够更好的发挥架构师的作用,更好的把利益的调整落到实处。架构师的前提条件如果一个人在工作中,只是致力于完成自己的工作,以做好自己的工作为主要目标,那么最多只能成为一个工匠,无法成为一个架构师。因为这个过程解决的还是自己的问题,并没有时间的压力,可以随意什么时候做完都可以。架构师的权利和义务架构师是要去平衡别人的利益,甚至会调整别人的利益的。一旦架构师是全心全意的为别人的利益服务,自然而然的架构师就拥有了强有力的影响力,肯定会是一个leader。但是只是民意上的leader是没有用的,不能完全发挥架构师的能量。

       很多时候问题的产生都是因为沟通的误解,或者主观上有很多不必要的利益诉求导致的。但是总还有一部分确实是有问题的,需要做调整,那么就必须要有所动作,做相应的调整。这个调整就是架构的切分。所以切分是利益的调整。切分也需要有原则,这四个原则是:连续时间内的活动不能切分;权利义务对等;不超出一个人的负载;对外部透明。总结下来,架构的切分的导火索是人的负载太重。架构的切分实际就是对 stakeholder 的利益进行切分或合并,使得每个stakeholder 的权责是对等的,每个 stakeholder 可以为自己的利益负责。架构切分的最终结果都会体现在组织架构上,只有这样才能够让架构落地并推进。架构切分的结果一定是一个树状,这也是为什么会产生分层。层数越多沟通越多,效率越低,分层要越少越好。尽可能变成一颗平衡树,才能让整个系统的效率最大化。

       架构师,首先,架构师的前提条件,那就是发现问题并提出有效解决方案处理问题的人,架构师一定拥有丰富的经验和技术,而且他是调整利益平衡利益的人。之后,从架构的角度写代码,核心是分层,将业务,技术,逻辑处理分成各自耦合度相对降低的层次,让软件的运营成本降至最低,而且利于维护。最后就是理清技术、业务和架构的关系了。技术是为了解决业务的问题而产生的,没有了业务,技术就没有了存在的前提。有了更好的技术,效率更差的技术就会被淘汰,一切都遵从人类的利益诉求—也就是业务。再者,在解决同一个业务的问题的前提下,更高效,更低成本的技术将代替其他技术。所以架构师应该承担起解决业务问题的角色,也需要具备识别技术采取技术相应的能力。

标签:架构,有感,不同,漫谈,问题,切分,利益,架构师
From: https://www.cnblogs.com/clh628/p/18041775

相关文章

  • 架构漫谈读后感
    今天在阅读了王概凯先生的架构漫谈博客之后,激发了我很多对软件架构深刻的思考。这篇博文不仅仅是一个关于软件架构的技术性解读,更像是一次智慧的碰撞和思维的火花,让我对架构设计有了更加深刻的认识。从九个问题出发,让我深刻的了解了软件架构。对软件架构有了深刻的思考。(一)什么......
  • 读架构漫谈有感
    每当我们开发新的项目的时候都会新建一个解决方案,然后在解决方案中搭建N个项目。每个项目之间通过“引用”达到交互的功能,这个过程就可以称之架构,而架构最终的产物则是软件产品。不同的程序员在搭建架构的时候分两种情况:熟悉业务,根据业务进行架构、不熟悉业务,根据自己的理......
  • 架构漫谈读后感
    作者以一种通俗易懂的语言,向我们揭示了软件架构的本质与核心价值。它并非仅仅是代码堆砌的艺术,而是对系统逻辑、业务需求、性能考量、可扩展性、可维护性等多方面因素进行综合权衡与设计的过程。作者通过生动具体的案例,阐述了良好的架构设计如何影响并决定着项目的成败,使我对架构......
  • 架构漫谈读后感
    什么是架构:架构产生的必要条件包括:必须由人执行的工作;每个人的能力有限;每个人的时间有限;人们对目标系统有更高要求;目标系统的复杂性超出单个人的能力范围。架构的本质是对目标系统的规划、设计和构建过程,具体体现为:根据要解决的问题,明确目标系统的边界;基于某个原则对......
  • 架构漫谈读后感
    架构设计中的问题识别与切分在阅读了所提供的四篇关于架构设计中问题识别与切分的文章后,我对于架构设计这一复杂而关键的领域有了更深入的理解。这些文章深入探讨了问题识别、切分原则以及与利益相关的重要性,为我提供了宝贵的思考和启发。首先,文章着重强调了在解决问题......
  • 架构漫谈读后感
    为什么会产生架构?想象一下,在最早期,每个人都完全独立生活,衣、食、住、行等等全部都自己搞定,整个人类都是独立的个体,不相往来。为了解决人类的延续的问题,自然而然就有男女群居出现,这个时候就出现了分工了,男性和女性所做的事情就会有一定的分工,可是人每天生活的基本需求没有发生变化......
  • 架构漫谈读后感
    今天第一次接触软件架构这门课程,首先阅读了架构漫谈这一系列博客的前三篇,初步了解了什么是架构、认识概念是理解架构的基础以及如何做好架构之识别问题。要谈软件架构,首先要了解什么是架构,这对我来说是一个新概念。所谓架构,起先源于建筑学,后来广而用之,在社会各个方面行业......
  • 架构漫谈读后感
    架构产生的动力主要源自以下几个方面:自动化程度有限:对于需要人工干预才能完成的工作,即使存在一定程度的自动化,仍需要架构来协助规划和设计。个体能力和专注度有限:每个人都有自己擅长的领域,但由于个人能力和专注度的限制,单个人很难完成复杂系统的设计和实施。因此,需要将工作分解......
  • 架构漫谈——1500字
    架构漫谈:首先是什么是架构,读完之后我自己的对架构的理解就是一种为了方便人们解决问题的一种方案,具体是怎么方便解决问题的呢? 总结下来:先对问题进行分析,再对问题进行切分,由不同的人进行不同的工作,然后使这些部分有机的结合为一个整体,这就是架构,是一个方便解决问题的过程。接......
  • 2.28王概凯架构漫谈读后感
    架构漫谈是由一个架构师王概凯写的一个专题,是以他的实际架构经验为基础,讨论是什么是架构,怎样做好架构,怎么写好程序等一些问题。共分为九个部分:1) 什么是架构?首先把架构的概念讨论明白,然后在对架构进行分析才显得清晰有意义。架构这个词在软件工程很早之前就已经出现了,在人类的......