• 《架构漫谈》读后感


        今天,我阅读了《架构漫谈》。

        首先,什么是架构?架构就是把一个整体切分成不同的部分,有不同的角色来完成这些分工,并通过建立不同的部分相互沟通的机制,使这些部分能够有机的结合为一个整体,并完成这个整体所需要的所有活动。架构产生的动力有:1.必须由人执行的工作;2.每个人的能力有限;3.每个人的时间有限;4.人对目标系统有更高的要求;5.目标系统的复杂性使得单人完成这个系统基本上是不可能的。

        第二,讲了认识概念是理解架构的基础。在前一篇中提到,架构实际上是解决人的问题,而概念是人认识这个世界的基础。在第二篇中通过讲述何为相?让我们理解了当一个概念提出来给我们的时候,我们是否能够挖掘出概念背后的问题。

        第三,讲了我们想要做好架构,首先我们需要识别出需要解决的问题,文中以切土豆为例。通过这个例子,我知道了当用户向你提出一个需求的时候。我们不能只停留在这个问题的表面。我们需要从全局的角度看待这个问题。他要的仅仅是他说的吗?他提出这需求的根本目的是什么?他实际上是要解决什么问题。我们怎么做可以让涉众满意?

        第四,讲了我们想做好架构,工作量与利益切分一定要做好。一个不好的架构在切分问题上会出现下列问题:1.某人或者某些利益相关人负载太重;2.时间上负载太重;3.空间上的负载太重,本质上还是时间上的负载太重;4.某人或者某些利益相关人权利和义务不对等。

    一个好的架构在切分问题上遵循以下几个原则:1.必须在连续时间内发生一个活动,不能切分;2.切分出来部分的负责人,对这个部分的权利和义务是对等的;3.切分出来的部分,不应该超过一个自然人的负载;4.切分是内部活动,内部无论怎么切,对整个外部应该是透明的。

        第五,讲了什么是软件?软件实际上就是我们将一些我们日常生活中所作的事情,包括我们本人都一起虚拟化到了计算机中。通过计算机的输入输出设备,控制计算机中的自己,来完成日常工作的一种应用。也就是说人是软件发展的动力。随着时代的发展,一个人已经很难独立的完成一款软件。这就需要架构将我们每一个人所需要完成的工作阐述出来。

        第六,讲了软件架构到底是要解决什么样的问题?首先讲了软件架构是要解决业务问题和计算机的问题。业务问题的本质,是业务所务的对象的利益问题。为了能够让软件很好的跑起来,软件工程师必须理解业务所服务对象,他们的利益在哪儿。主要就是为了解决这两方面的问题。

        第七,主要站在企业领导者的角度讲述了不要空设架构师这个职位,给他实权。架构师必须是一个组织的领导人,有权利调动这个组织,才能更好的发挥架构师的作用,更好的把利益落到实处。很多公司设了很多架构师的职位,但是并不具备调动组织架构的权利,那么这个架构师的职位一定是形同虚设。架构师只能够通过建立某些流程来行使架构师的权利,比如强制架构review,反过来造成内部很多不必要的冲突,最终都会导致这些流程流于形式,得不偿失。相信很多人已经历过这些,但似乎很少有人回去探讨这是为什么。反过来,具备架构师能力的领导人,一定是一个很好的领导,这个组织一定是很健康向上的,因为每个人的权利和义务就是比较均等的。

        第八,讲了从架构的角度看如何写好代码。再前面提到,软件实际上是对现实生活的模拟,虚拟化。这就决定了我们代码应该分为几个部分。结合每个部署单元所承担的责任,可以明确的拆分为两个不同的责任:1.表示业务逻辑的代码;2.对用户提供访问并保存业务逻辑运行结果的代码。

        第九,讲了理清技术、业务和架构的关系。技术就是通过人为创造条件,让指定的规律按人的意愿发生。业务就是我们需要解决的问题。实际上就是用户的利益。技术是为了解决业务问题而产生的。有了更好的技术,更差的技术就会慢慢被淘汰。一般先有技术,才会有架构。不同的技术,通过树状结构组合在一起,形成了一个完整的架构解决方案,共同完成业务的目标。这就是技术、业务、架构之间的关系。

      

  • 相关阅读:
    Spring_依赖注入DI
    Spring_懒加载与非懒加载
    Spring_提示模板配置/搭建spring框架/单例与多例/初始化方法和销毁方法
    Spring
    Mybatis_二级缓存
    Mybatis_一级缓存
    Mybatis_一对多延迟加载
    Mybatis_一对一查询
    MapReduce的核心资料索引 [转]
    Hadoop家族的各个成员
  • 原文地址:https://www.cnblogs.com/ygl888/p/6497920.html
Copyright © 2020-2023  润新知