架构漫谈

　本学期开设了一门软件体系结构的课程，王老师给我们推荐了一系列关于架构的专栏文章，该专栏由资深架构师王概凯 Kevin 执笔，文章共分为九篇，层次分明的讲述了什么是架构、怎样做好架构、软件架构如何落地、如何写好程序等问题，文章十分生动形象，各种通俗的例子信手拈来，使得本来生涩难懂的知识变得形象起来，便于我们理解。通过对这九篇文章的阅读理解，其中有一些让我印象十分深刻的东西，比如：一直在挖掘一些本质的东西，对一些看似基础的东西进行深度地思考，就像“概念”，得出“概念是人的某一需求的解决方案”的结论。这让我认识到了自己在思维方式方面的不足，以后需要注意思考，打开思路。

通过阅读，我研究了以下几个问题：

什么是架构？

1.根据要解决的问题，对目标系统的边界进行界定。

2.并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。

3.并对这些切分出来的部分，设立沟通机制。

4.根据 3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。

　　架构是为了解决的人的问题，找出问题的主体，是做架构的首要问题。要思考“是解决谁的问题”，先找到是“谁”，再去分析所需解决的问题。识别出问题后，对于确实有问题的部分要根据利益进行切分。切分的原则：1.必须在连续时间内发生的一个活动，不能切分。2.切分出来的部分的负责人，对这个部分的权利和义务必须是对等的。3.切分出来的部分，不应该超出一个自然人的负载。当然对于每个人的能力不同，负载能力也不一样，需要不断的根据实际情况调整，这实际上就是运营。4.切分是内部活动，内部无任怎么切，对整个系统的外部应该是透明的。

架构产生的动力是什么？：

1.必须由人执行的工作（不需要人介入，就意味着不需要改造，也就不需要架构了）

2.每个人的能力有限（每个人都有自己的强项，个人的产出受限于最短板，并且由于人的结构限制，同时只能专注于做好一件事情，比如虽然有两只眼睛，但是只能同时专注于一件事物，有两只手，无法同时做不同的事情。ps. 虽然有少部分人可以左手画圆右手画框，但是不是普遍现象）

3.每个人的时间有限（为了减少时间的投入，必然会导致把工作分解出去，给擅长于这些工作的角色来完成，见 2，从而缩短时间）

4.人对目标系统有更高的要求（如果满足于现状，也就不需要进行架构了）

5.目标系统的复杂性使得单个人完成这个系统，满足条件 2，3（如果个人就可以完成系统的提高，也不需要别的人参与，也就不需要架构的涉及，只是工匠，并且一般这个工作对时间的要求也不迫切。当足够熟练之后，也会有一定的架构思考，但考虑更多的是如何提高质量，提高个人的时间效率）

关于切分的小结：

1.架构的切分的导火索是人的负载太重。

2.架构的切分实际就是对 stakeholder（利益相关者） 的利益进行切分或合并，使得每个 stakeholder 的权责是对等的，每个 stakeholder 可以为自己的利益负责。

3.架构切分的最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进。

4.架构切分的结果一定是一个树状，尽量扁平化。

软件架构

软件架构出现的导火索也是软件工程师的任务太重，需要把很多工作拆分出来。软件架构作用于两个方面，一是业务的owner，他需要提高业务的效率，降低业务的成本。二是软件工程师，必须要理解业务所服务的对象，从而将业务虚拟化，让软件很好的跑起来。

还了解了一下关于架构师：

架构师要解决的是别人的问题，不是自己完成工作的问题。架构师必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好的发挥架构师的作用，更好的把利益的调整落到实处。我认为一名架构师，在技术上需要有足够的自信，这样才能够去领导别人去做软件，同时也会受到信服。当遇到问题时，能提出解决问题的成本最低的方案，就是一名架构师应该做的。

转载于:https://www.cnblogs.com/sakura--/p/10507747.html