架构漫谈读后感

读架构漫谈有感今天，在老师的推荐下，读了架构漫谈，《架构漫谈》是由资深架构师王概凯 Kevin 执笔的系列专栏，专栏将会以 Kevin 的架构经验为基础，逐步讨论什么是架构、怎样做好架构、软件架构如何落地、如何写好程序等问题。由于时间有限以及自身能力的限制，所以只读了《架构漫谈》前四章的内容，自此，对架构漫谈有了一个自己的理解。在软件这个行业内，每个人都有着自己的礼节，所以争论从来没有停止过。而在一个整体中，由于为了生存发展，所以人们不得不进行分工合作，每个人都是整体的一部分，但是各个部分又是紧密相连，互相交流，每个人都在做自己擅长做的事，再使整体生产力发展的同时，自己的生产力也有了极大的进步。以上面这个例子为例，把一个整体切分成不同的部分，由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，这就是架构。由以上的例子，也可以归纳出架构产生的动力：必须由人执行的工作，每个人的能力有限，每个人的时间有限，人对目标系统有更高的要求，目标系统的复杂性使得单个人完成这个系统，满足条件（如果个人就可以完成系统的提高，也不需要别的人参与，也就不需要架构的涉及，只是工匠，并且一般这个工作对时间的要求也不迫切。当足够熟练之后，也会有一定的架构思考，但考虑更多的是如何提高质量，提高个人的时间效率），这是作者给出的定义，我总结之后为：把事物进行切分，而每一部分能够互相联通，在老师的提点和给出了更高的总结之后，我也认为其更好的定义是：复杂问题简单化，简单问题流程化。以上解决了什么是架构的问题，那么架构是用来解决谁的问题呢？架构实际上解决的是人的问题，而概念是人认识这个世界的基础，自然概念的认识就非常的重要。每个概念实际上所解决的，还是人遇到的某个特定的问题，我们把解决问题的解决方案，给定了一个名字，这个名字就是对应的某个特定的概念。对于概念这个词本身，为了统一指代这些名字，我们称起这类作用的名字称为“概念”。根据架构的定义，要做好架构所首先必须具备的能力，就是能够正确的认识概念，能够发现概念背后所代表的问题，进而才能够认识目标领域所需要解决的问题，这样才能够为做好架构打好基础。事实上，这一能力，在任何一个领域都是适用的。找出问题的主体，是做架构的首要问题。这也是我一再强调的，我们要解决的问题，一定都是人的问题。更进一步，架构师要解决的，基本都是别人的问题，不是自己的问题。而在认识问题之后架构师就要开始对其进行切分，因为工作量的庞大，不可能让一个人完成全部工作，那切分的依据是什么呢？必须在连续时间内发生的一个活动，不能切分。比如孕妇怀孕，必须要 10 月怀胎，不能够切成 10 个人一个月完成。切分出来的部分的负责人，对这个部分的权利和义务必须是对等的。因为如果权利和义务是不对等的话，会伤害每个个体的利益，分出来执行的效率会比没有分出来还要低，实际上也损害了整体的利益，这违背了提升整体利益的初衷。切分出来的部分，不应该超出一个自然人的负载。当然对于每个人的能力不同，负载能力也不一样，需要不断的根据实际情况调整，这实际上就是运营。切分是内部活动，内部无任怎么切，对整个系统的外部应该是透明的。如果因为切分导致整个系统解决的问题发生了变化，那么这个变化不属于架构的活动。当然很多时候当我们把问题分析的比较清楚的时候，整个系统的边界会进一步的完善，这就会形成螺旋式的进化。但这不属于架构所应该解决的问题。进化的发生，也会导致新的架构的切分。