首页 > 其他分享 >读后感

读后感

时间:2023-02-18 20:00:55浏览次数:27  
标签:读后感 架构 每个 技术 业务 问题 架构师

讲的是到底什么是架构,在我看来:就是把一整体划分为不同角色,各自完成自己的部分,最后有机的融合在一起。然后通过一个早期的例子来笼统地概括他的出现。在最早期,每个人都完全独立生活,衣、食、住、行等等全部都自己搞定,整个人类都是独立的个体,不相往来。为了解决人类的延续的问题,自然而然就有男女群居出现,这个时候就出现了分工了,男性和女性所做的事情就会有一定的分工,可是人每天生活的基本需求没有发生变化,还是衣食住行等生活必须品。但是一旦多人分工配合作为生存的整体,力量就显得强大多了,所以也自然的形成了族群:有些人种田厉害,有些人制作工具厉害,有些地方适合产出粮食,有些地方适合产出棉花等,就自然形成了人的分群,地域的分群。当分工发生后,实际上每个人的生产力都得到了提高,因为做的都是每个人擅长的事情讲的是认识概念。架构实际上解决的是人的问题,举个例子,看到一个东西,比方说杯子,“杯子”就是一个名字,指代的看到的东西就是相,就是事物的相状。我们一听到“杯子”这个词,脑海里就会浮现出一个杯子的形象。而“杯子”这个词,是用来指代的是这个相状的,叫做名。合起来就叫做“名相”。每个概念都是因解决问题而产生的,最后我们把解决问题的解决方案,命名了一个名字,这个名字就是概念讲的是识别问题。首先通过一则笑话:女主人公:老公,把袋子里的土豆切一半下锅。结果老公是把袋子里的每个土豆都削了一半,然后下锅。每个人都做了很多工作,每个人都认为自己做的是对的,因此没有一个人对结果满意。因为真正的问题没有被发现,自然也就没有被解决,那么后续还得收拾残局,还要继续解决问题。事实上自己的工作并没有完成,反而更多了。把原因归结为沟通问题也是可以的,但对于解决问题似乎并没有太多的帮助。因为要改进沟通,这也是一个大问题。搞明白目标问题“是谁的问题,是什么问题”,当然也是需要沟通的。为了帮助自己更快的搞明白,首先要做的事是问正确的问题。架构师应该问的第一个正确的问题就是:目标问题是谁的问题。 在项目开发阶段,团队之间必备的就是沟通,如果沟通不好,项目组就会问题百出架构切分。我们已经知道,随着社会的发展,分工是必然的。每个人做着不同的工作,也可以说做着自己更为擅长的工作,各尽其职。这个背后的动力就是每个人自己的利益。每个人都希望能够把自己的利益最大化。在这个模式下,每个人必须要舍掉自己的东西,才能够得到更多的东西。牛顿第三定律也告诉我们想走必须留下点儿东西。讲的什么是软件。软件的产生就是人类在计算机上有意无意地模拟人的行为。软件早期是由程序员编写的,提高了自己的生产力,慢慢软件就变成了一个独立的行业。从最初的一个人完成,也逐渐变成多人分工完成。架构要解决什么问题。架构实际上是在量不断的增大,超过了单台服务器的容量,逐渐的分拆,同时导致超过单个人员的能力,工作人员不断的增多,工作内容不断的分拆形成的。这本身就是架构的意义所在。不管怎么分拆,所达到的目标没有任何变化,就是完成业务在计算机中的虚拟化给架构师实权。架构师是要去平衡别人的利益,甚至会调整别人的利益的。一旦架构师是全心全意的为别人的利益服务,自然而然的架构师就拥有了强有力的影响力,肯定会是一个leader。但是只是民意上的leader是没有用的,不能完全发挥架构师的能量。架构师必须是一个组织的领导人,有权利调动这个组织的架构,才能够更好的发挥架构师的作用,更好的把利益的调整落到实处。如何写好代码。作为一个软件工作者,无论干什么,编码是必不可少的。我们真正想快速的完成代码工作,就要克服自己对时间的恐惧,真正的去研究业务的问题。结合每个部署单元所承担的责任,可以明确的拆分为两个不同的责任:表达业务逻辑的代码,对用户提供访问并保存业务逻辑运行结果的代码。理清技术、业务和架构的关系:技术是为了解决业务的问题而产生的,没有了业务,技术就没有了存在的前提。有了更好的技术,效率更差的技术,就会慢慢的被淘汰,消失,一切都遵从人类的利益诉求 -- 也就是业务。有人会问,不用钻木取火了,但是弓弦加速转动木棍还可以用啊? 没错,因为弓弦转动木棍这个技术,不是来生火的,是用来加速木棍转动的,所解决的问题不一样。但是两种不同的技术,合理结合起来,会更好更有效率的解决业务问题,在解决同一个业务问题的前提下,更高效,更低成本的技术,会淘汰低效,高成本的技术。这是人类利益诉求所决定的。一般刚开始解决根本问题的技术(钻木取火)的效率是比较低的,只是把不可能变成了可能。然后就会有提高效率的需求出现,要求改进这个技术。这个技术的低效率部分就会被其他人(或者技术发明人自己)加以改进,这部分就会形成新的技术。

 

标签:读后感,架构,每个,技术,业务,问题,架构师
From: https://www.cnblogs.com/CXLRG/p/17133444.html

相关文章

  • 《架构漫谈》读后感
    今日学习了架构漫谈,逐步由浅入深讨论了架构的内涵,做好架构的途径,架构落地问题以及如何去编写优秀的程序。通过对该专栏的了解,我对架构有了新的认识与感悟。首先需......
  • 《架构漫谈》读后感
    这几天,读了老师推荐有关架构的一篇系列文章《架构漫谈》,其中通俗易懂的语言,风趣幽默的风格,形象明了的对比形式让我对架构有了更进一步的了解。当阅读《架构漫谈》这本书后......
  • 《架构漫谈》读后感
    1.         什么是架构:作者说架构实际上就是指人们根据自己对世界的认识,为解决某个问题,主动地、有目的地去识别问题,并进行分解、合并,解决这个问题的实践活动。架......
  • 架构漫谈读后感
    今天阅读了王概凯的架构漫谈,下面我从以下几点来表达一下自己的认识.第一节讲的是架构的概念及其背景,文章首先引用了Wikipedia上的定义,然后通过早期人类分工合作的例子,解......
  • 王概凯《架构漫谈》读后感
    根据我们的课程要求,我认真阅读了王概凯老师写的《架构漫谈》,理解了一下几个方面:(1)什么是架构把一个整体(完成人类生存的所有工作)切分成不同的部分(分工),由不同角色来完成这些......
  • 架构漫谈读后感
    架构漫谈指出的问题:什么是架构,架构为谁服务,以及为什么要有架构。用一句话总结就是架构服务于人,将复杂问题简单化,简单问题流程化。文章指出,每个角色的能力都是有限......
  • 王概凯《架构漫谈》读后感
    2023年2月18日   今天完成了老师的任务,在博客里面认真阅读了王概凯老师的《架构漫谈》,里面着重介绍了王概凯老师对于架构的看法和介绍,鉴于最近ChatGPT的大热,对于未......
  • 架构漫谈读后感
    这些博客是讲软件架构的,也是讲软件架构师的。他把软件开发比喻为盖房子,他提出了一个重要的理念:高质量、可复用。关于高质量,我们都知道软件开发需要以工程的方式进行,这就要......
  • 架构漫谈读后感
    王概凯的这些关于架构的漫谈用了不少的例子对复杂的概念进行具现,通过这些的东西使得我对架构的知识点有了更多的认识。架构是软件开发中的一个重要概念,它是一种软件系......
  • 架构漫谈读后感
    读架构漫谈有感今天,在老师的推荐下,读了架构漫谈,《架构漫谈》是由资深架构师王概凯Kevin执笔的系列专栏,专栏将会以Kevin的架构经验为基础,逐步讨论什么是架构、怎样做好......