标签：读后感 架构 漫谈 软件体系结构 问题 三下 软件 解决 架构师

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

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

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

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

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

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

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

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

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。