架构漫谈

在上本学期软件体系架构课程之初，我阅读了王概凯老师的《架构漫谈》博客文章，王老师以很多生动的例子为我们讲解了什么是架构、认识概念、识别问题、架构切分、什么是软件、什么是架构师、从架构的角度来看如何写好代码以及技术、业务、架构三者的关系。在我看来软件架构最好放在小的场景中理解。我们有2个页面。1.页面A：主页面2.页面B：详情页面2个页面分别显示一个数字，这个数字应该相同。详情会修改这个数字，这里我们发现，详情页面和主页面数字不一样。数据不一致这里首先的感觉就是，详情页面返回，主页面数据没有刷新，导致数据不一致。

　　首先，什么是架构？什么会有架构？在人刚刚学会生存时是没有架构，一个人包揽了所有的工作（可能也会有时间的架构，先做什么，后做什么），但是随着人类的繁衍，种群的扩大，人们学会使用火，学会制造工具，种植作物时，每个人的特点就会显现出来。，有的人擅长捕猎，有的人手巧，擅长制作工具，而有的人种庄稼很厉害，而且每个人的时间也是有限的，这时就出现了分工。人们将事情分开，由不同的人来完成不同的工作，最后进行交易，这实际上就是社会的架构。

　　而架构产生的动力有以下几条：

　　①由人进行的工作（只有人做这个工作，人们才会想怎样对他进行改进优化，从而提高系统的质量）。

　　②每个人的能力有限，正如上面的例子所说，每个人擅长的东西不一样，如果让一个擅长制作工具的人去种庄稼，那他90%的可能要比擅长种庄稼的人花费的时间多，而且做得比如人家好，而让这个擅长种庄稼的人去制作工具，那他也没有擅长制作工具的人做得好。

　　③每个人的时间有限，比如一个人盖一幢房子需要2个月，而10个人可能10天就完成了，为了减少时间的投入，必然需要把工作分出去，让擅长该供工作的人完成。

　　④人对目标系统有更高的要求，还是房子的例子，如果人们对居住环境没有更高的要求，而只是要求能住人就行，那么我们现在可能还是居住在山洞中，因为不满足仅仅能住人，还要能做饭、能洗澡、能娱乐，所以出现了架构。

　　综上，总结一下什么是架构，根据目标系统的要求划定系统边界，然后按照某种原则对问题进行划分、合并，最终解决问题的实践过程。架构实际上解决的是人的问题，

　　划分问题的前提是我们应该能够识别问题，正确找出问题才能划定系统边界。此处，以老师上课讲过的一个关于软件需求的漫画为例：

这则漫画主要是描述在实际制作秋千这个需求过程中，各个部门之间的理解配合及完成需求的差异。首先，产品经理没有听懂用户的需求，没有找的真正的问题，而是想当然应该这样做，而且想得过于简单没有站在用户的角度想。在架构中我们应先找到问题的主体，其次去找到真正的问题。因为问题的主体是问题的隐含边界，边界不确定下来，问题就是不确定的。一旦确定了主体，剩下的就是去搞明白主体有哪些问题。在这个秋千中，我们首先找到问题的主体是乘坐秋千的孩子，问题是想要一个秋千，秋千最起码能荡起来，而在图二中显然设计的不符合需求。所以，当我们在做架构时，首先确定这是谁的问题？问题是什么？当这两个问题解决好，我们就确定了系统的边界。

　　确定系统边界后我们就应该进行划分，当一个系统比较复杂时，必然会进行切分，而切分的背后必然与利益有关，每个人都希望自己利益最大化。但是每个人的能力和时间都非常的有限，不可能什么都懂，所以自然需要舍掉一些自己不擅长的东西，用自己擅长的东西去换取别人擅长的东西。那么在一个系统中我们应如何进行切分呢？切分有以下几个原则：

　　①必须在连续时间内发生的一个活动不能进行切分。

　　②切分出来的部分的负责人，对这个部分的权利和义务必须是对等的。

　　③切分出来的部分，不应该超出一个自然人的负载。

　　④切分是内部活动，内部无任怎么切，对整个系统的外部应该是透明的。如果因为切分导致整个系统解决的问题发生了变化，那么这个变化不属于架构的活动。

　　王概凯老师对于软件架构的知识讲解的详细生动，此处只写了一部分内容，接下来会进行进一步的学习，了解系统合成及架构师的工作等内容。