架构漫谈读后感

　　近日读了老师推荐的《架构漫谈》系列内容，对软件架构的认识有了更加深刻的理解。

　　首先提到架构，就要说到什么是架构，作者在文中对架构的定义是这样的：把一个整体切分成不同的部分，由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动。总的来说，架构就是：1、根据要解决的问题，对目标系统的边界进行界定。2、对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。3、并对这些切分出来的部分，设立沟通机制。4、根据第三点，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。

　　做好架构所首先必须具备的能力，就是能够正确的认识概念，能够发现概念背后所代表的问题，进而才能够认识目标领域所需要解决的问题，这样才能够为做好架构打好基础。做架构的很多时候都是在一个新的领域解决问题，必须要快速进入并掌握这个领域，然后才能够正确的解决问题。因此认识概念是理解架构的基础，学习新的技术或者概念、快速进入一个新的领域，会有利于帮助我们在架构阶段，快速的识别和定位问题。其次是切分，我们要对整个项目需求进行切分，还要把控对于利益的调整。一旦确认问题的主体，我们接下来会发现如下问题，某个或者某些利益相关人负载太重，或者时间上空间上负载太重，或者某个，某些利益相关人的权利和义务不对等。所以我们需要在一定原则上进行切分，第一是自然就无法切分的部分，第二是不违反人性。对比一个人干所有的事情，结果就是大家都能够得到更多，当然也产生了一个互相依赖的社会，互相谁都离不开谁。

　　如同前面描述的架构的定义，软件架构的出现也是同样的。随着互联网的发展，人类社会也开始软件化，实际上，我们是把我们日常生活中所做的事情虚拟化到了计算机中。随着软件的规模的变大，做好一个软件也变得越来越难了。早期的程序员写程序，主要是为了帮助自己研究课题。这些程序员熟练了之后，提高了自己的生产力，并发现还可以帮助别人写程序，慢慢软件就变成了一个独立的行业。程序从早期由一个人完成，也逐渐变成了由很多不同角色的人共同合作来完成。一开始是懵懵懂懂的去写软件，后来慢慢的就有意识的去切分，演变成了不同的架构。这个背后的动力也是一样的，就是提升参与的人的利益，降低成本。

　　代码架构属于软件架构的一部分，同样还有承载代码运行的硬件部署架构。实际上，硬件部署架构最终还是由代码的架构来决定。因为代码架构不合理，是无法把一个运行单元分拆出多个来的，那么硬件架构能分拆的就非常的有限，整个系统最终很难长的更大。我们真正想快速的完成代码工作，就要克服自己对时间的恐惧，真正的去研究业务的问题、利益相关者的利益，把这个变成我们的习惯。写代码的时候让该出现逻辑的地方出现逻辑，让不该出现的地方不能出现。一旦不该出现的地方出现了逻辑，那么要马上意识到，这个地方是一个坑，这个问题一定和业务的分析不透彻有关系。

　　成为软件架构师的前提条件，那就是发现问题并提出有效解决方案处理问题的人，架构师一定拥有丰富的经验和技术，而且他是调整利益平衡利益的人。之后，从架构的角度写代码，核心是分层，将业务，技术，逻辑处理分成各自耦合度相对降低的层次，让软件的运营成本降至最低，而且利于维护。

最后就是理清技术、业务和架构的关系了。技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。有了更好的技术，效率更差的技术就会被淘汰，一切都遵从人类的利益诉求—也就是业务。再者，在解决同一个业务的问题的前提下，更高效，更低成本的技术将代替其他技术。所以架构师应该承担起解决业务问题的角色，也需要具备识别技术采取技术相应的能力。