zoukankan      html  css  js  c++  java
  • 《架构漫谈》读后感

      架构漫谈的第一部分主要分析了什么是架构,以及架构产生的原因,我们从中可以总结出,架构产生的动力:1必须由人执行的工作(不需要人介入,就意味着不需要改造,也就不需要架构了),2每个人的能力有限(每个人都有自己的强项,个人的产出受限于最短板,并且由于人的结构限制,同时只能专注于做好一件事情,比如虽然有两只眼睛,但是只能同时专注于一件事物,有两只手,无法同时做不同的事情。)3每个人的时间有限(为了减少时间的投入,必然会导致把工作分解出去,给擅长于这些工作的角色来完成,见2,从而缩短时间)4人对目标系统有更高的要求(如果满足于现状,也就不需要进行架构了)5目标系统的复杂性使得单个人完成这个系统,满足条件2,3(如果个人就可以完成系统的提高,也不需要别的人参与,也就不需要架构的涉及,只是工匠,并且一般这个工作对时间的要求也不迫切。当足够熟练之后,也会有一定的架构思考,但考虑更多的是如何提高质量,提高个人的时间效率)。而从建筑的发展我们也可以总结出架构大体是什么,根据要解决的问题,对目标系统的边界进行界定,并对目标系统按某个原则的进行切分,切分的原则,要便于不同的角色,对切分出来的部分,并行或串行开展工作,一般并行才能减少时间,并对这些切分出来的部分,设立沟通机制,根据以上,使得这些部分之间能够进行有机的联系,合并组装成为一个整体,完成目标系统的所有工作。

      在第二部分,作者主要强调了架构是在解决人的问题,以及相和相的作用有哪些。“相“表达的不是一个具体的东西,相实际上代表的是这个作用,并不是具体的某个东西,而名是用来标识这个作用的,用来交流的。

      在第三部分中,作者主要在说如何解决架构的识别问题,当我们处理问题的时候,如果发现自己正在致力于把自己的工作完成,要马上警惕起来,因为这样下去会演变成没有ownership的工作态度。在面对概念的时候,也会不求甚解,最终会导致没有真正的理解概念。作为软件工程师或者架构师,我们大部分时候是要去解决别人的问题,“别人”是谁,是值得好好思考的。

      在第四部分中,作者提到了如何做好关于架构的切分的问题。我们要非常的清楚,所有的切分调整,都是对相关人的利益的调整。为什么这么说呢,因为维护自己的利益,是每个人的本性,是在骨子里面的,我们不能逃避这一点。我们已经知道,随着社会的发展,分工是必然的,为什么呢? 这个背后的动力就是每个人自己的利益。每个人都希望能够把自己的利益最大化。在这个模式下,每个人必须要舍掉自己的东西,才能够得到更多的东西。

      在第五部分中,作者提到了什么是软件, 有了软件之后,实际上,我们是把我们日常生活中所做的事情,包括我们自己本人都一起虚拟化到了计算机中。而人则演化成了,通过计算机的输入输出设备,控制计算机中的自己,来完成日常的工作,以及与其他人的沟通。也就是说,软件一直以来的动力,始终都是来模拟人和这个社会的。比如模拟大气运动(天气预报),模拟人类社会(互联网社交),模拟交易,包括现在正在流行的VR,人工智能等等。模拟的对象越来越高级,难度越来越大。不管如何发展,模拟人的所有行为都是一个大的趋势。也就是说,软件的主要目的,还是把人类的生活模拟化,提供更低成本,高效率的新的生活。从这个角度来看,软件主要依赖的还是人类的生活知识。

      在第六部分中,作者提出了有关于软件架构要解决谁的问题的问题,软件实际上就是把现实生活模拟到计算机中,并且软件是需要在计算机的硬件中运行起来的。要做到这一点需要解决两个问题,业务问题和计算机问题。业务的owner需要提升业务的效率,降低业务的成本,这是动机。这个实际上就是业务的问题,所以一般软件开发的出发点就在这里。是软件工程师的问题,要解决业务owner把业务虚拟化的问题,并且要解决软件开发和运营的生命周期的问题。

      架构漫谈的第七部分,告诉了读者,要给架构师实权, 架构师必须是一个组织的领导人,有权利调动这个组织的架构,才能够更好的发挥架构师的作用,更好的把利益的调整落到实处。所以很多公司设了很多架构师的职位,但是并不具备调动组织架构的权利,那么这个架构师的职位一定是形同虚设。架构师只能够通过建立某些流程来行使架构师的权利,比如强制架构review,反而会造成很多内部不必要的冲突,最终都会导致这些流程流于形式,得不偿失。

      在第八部分中,作者以他的经验告诉了我们如何从架构的角度写代码。结合每个部署单元所承担的责任,可以明确的拆分为两个不同的责任:表达业务逻辑的代码,对用户提供访问并保存业务逻辑运行结果的代码。,逻辑只允许存在于Business中,Service、Glue Code、Repository都不允许存在业务逻辑。

       在第九部分中,我了解了技术业务和架构之间的关系。在软件设计开发的过程中经常会看到,很多所谓的架构讨论实际上只是在讨论某种技术。在很多人的概念里面,架构和技术实际上是等同的。同时,技术人普遍看不起业务,认为技术更高端,而业务太低端,并且业务往往喜欢给技术挖坑。业务则觉得技术眼光高,但是实际解决不了问题。所以我们要理解业务,技术与架构到底有什么关系。技术是什么,过人为创造条件,让指定的规律按照人类的意愿发生,这就是技术。一般是先有技术,才会有架构。技术总是在人类解决对业务的要求不断提高的情况下产生,目的也是为了获取更大更好的利益。

  • 相关阅读:
    Finding Action Tubes
    Modeling Video Evolution For Action Recognition
    GBrank_问题列表
    annotation code for human pose estimation
    什么是 kNN 算法?
    什么是强化学习?
    什么是张量?
    什么是遗传/进化算法?
    什么是贝叶斯网络?
    什么是机器学习?
  • 原文地址:https://www.cnblogs.com/sunmei20142925/p/6488849.html
Copyright © 2011-2022 走看看