大三下 架构漫谈读后感

　　本学期的新课程软件体系结构，之前的编码经验对于软件体系结构的概念十分模糊。一是之前的项目体系太小，逻辑简单，对于体系结构没有太大的要求。二是对于软件体系没有基本的了解，好像也只有之前学的设计模式与软件体系结构沾点关系。在阅读了架构漫谈后，算是有了一些基本的了解。

　　首先什么是架构，文章的原话是“把一个整体（完成人类生存的所有工作）切分成不同的部分（分工），由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，这就是架构”。由于每个人的能力有限，且项目复杂不能由单人完成，所以要考虑分工并建立沟通机制以提高工作效率。架构实际上就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，并进行分解、合并，解决这个问题的实践活动。架构的产出物，自然就是对问题的分析，以及解决问题的方案：包括拆分的原则以及理由，沟通合并的原则以及理由，以及拆分，拆分出来的各个部分和合并所对应的角色和所需要的核心能力等。

　　每个概念实际上所解决的，还是人遇到的某个特定的问题，我们把解决问题的解决方案，给定了一个名字，这个名字就是对应的某个特定的概念。“架构”也是是同样的一个特定概念。架构师要解决的，基本都是别人的问题，不是自己的问题，任何找上架构师的问题，绝对都不是真正的问题。因为如果是真正的问题的话，提问题过来的人肯定都能够自己解决了，不需要找架构师。架构师都要有这个自觉：发现问题永远都比解决问题来的更加重要。

　　了解软件体系结构要了解什么是软件。软件其实是模拟人和社会，把我们乃至社会向虚拟化到计算机中，比如模拟大气运动（天气预报），模拟人类社会（互联网社交），模拟交易，包括现在正在流行的 VR，人工智能等等。模拟的对象越来越高级，难度越来越大。所以说软件的于目的是把人类的生活模拟化，提供更低成本，高效率的新的生活。从这个角度来看，软件主要依赖的还是人类的生活知识。

　　软件架构的出现，由于软件的复杂性，需要大量的计算机语言的知识以及相关领域的专业知识，这远远超出了个人的能力。所以软件开发就开始有分工了，行业知识和业务的识别，会交给BA，系统的设计会交给架构师，设计的实现交给架构师，实现的检验交给测试，还有很多其他角色的配合。为了组织这些角色的工作，还有项目经理。这就把原来一个人的连续工作，拆分成了不同角色的人的连续配合，演化成了不同的软件开发的模式。然后慢慢演变出专门为别人开发软件的软件公司。

　　什么是架构师，架构师必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好的发挥架构师的作用，更好的把利益的调整落到实处。架构师是要去平衡别人的利益，甚至会调整别人的利益的。一旦架构师是全心全意的为别人的利益服务，自然而然的架构师就拥有了强有力的影响力，肯定会是一个 leader。但是只是民意上的 leader 是没有用的，不能完全发挥架构师的能量。架构师必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好的发挥架构师的作用，更好的把利益的调整落到实处。

　　技术，业务与架构的关系。技术总是在人类解决对业务的要求不断提高的情况下产生，目的也是为了获取更大更好的利益。技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。有了更好的技术，效率更差的技术，就会慢慢的被淘汰，消失，一切都遵从人类的利益诉求–也就是业务。有人会问，不用钻木取火了，但是弓弦加速转动木棍还可以用啊？ 没错，因为弓弦转动木棍这个技术，不是来生火的，是用来加速木棍转动的，所解决的问题不一样。但是两种不同的技术，合理结合起来，会更好更有效率的解决业务问题。

标签：读后感,架构,漫谈,软件体系结构,问题,三下,软件,解决,架构师
来源： https://www.cnblogs.com/fengchuiguobanxia/p/15940522.html