《架构漫谈》读后感

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

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

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

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

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

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

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

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

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