架构漫谈读后感
今天在阅读了王概凯先生的架构漫谈博客之后，激发了我很多对软件架构深刻的思考。这篇博文不仅仅是一个关于软件架构的技术性解读，更像是一次智慧的碰撞和思维的火花，让我对架构设计有了更加深刻的认识。
从九个问题出发，让我深刻的了解了软件架构。对软件架构有了深刻的思考。
（一）什么是架构？
作者从建筑的角度出发，解释了架构的概念。它是规划、设计和构建的过程，同时也是这个过程的产出物。这个定义让我明白了架构的实质，即通过分工和合作，将一个整体切分成不同的部分，由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动。
同时作者也说明了架构产生的动力，包括必须由人执行的工作、每个人的能力有限、每个人的时间有限、人对目标系统有更高的要求以及目标系统的复杂性等五个条件。
（二）认识概念是理解架构的基础
作者通过具体例子（如桌子、杯子等）揭示了我们对日常概念的误解，概念的本质：概念不仅仅是一个名字或标签，它代表了某个特定问题的解决方案。例如，“杯子”不仅指代一个实物，而是为了解决单手持握、避免直接接触所盛物体的问题。概念与沟通：不同文化和语言中，虽然名称可能不同，但面对的问题是相似的，因此可以相互翻译和理解。抽象的误解：抽象通常被认为是将不同事物的相似部分合并，但实际上，抽象是一个分类过程，形成的新概念与原概念解决的问题并不相同。强调了对概念深入理解的重要性，这不仅有助于架构工作，也有助于快速学习和掌握新的技术和领域。
（三）如何做好架构之识别问题
作者从四个方面进行说明识别问题。
-
识别问题的困难：
- 人们往往过于关注解决问题，而忽视了真正的问题是什么。
- 通常，问题的描述缺乏主语，导致沟通和理解上的误差。
-
如何识别问题：
- 首先要明确问题的主体，即“是谁的问题”。这有助于确定问题的边界。
- 识别问题主体后，可以更直接地了解问题的实际情况，从而更准确地解决问题。
-
问题的主体与边界：
- 一旦确定了问题的主体，问题的边界自然明确。这有助于更深入地理解问题的本质。
- 问题的主体通常是人，因此架构师应注重解决他人的问题，而非自己的问题。
-
寻找问题的根源：
- 当问题暴露时，应从暴露点开始，逐步溯源以找到问题的真正来源。
- 如果无法确定问题的主体，应尽量降低问题带来的成本，并隔离影响范围。
（四）如何做好架构之架构切分
作者讨论了为什么需要切分、切分的原则、切分与建模、切分的输出和组织架构等问题。然后做出以下总结：
- 架构的切分的导火索是人的负载太重。
- 架构的切分实际就是对 stakeholder 的利益进行切分或合并，使得每个 stakeholder 的权责是对等的，每个 stakeholder 可以为自己的利益负责。
- 架构切分的最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进。
- 架构切分的结果一定是一个树状，这也是为什么会产生分层。层数越多沟通越多，效率越低，分层要越少越好。尽可能变成一颗平衡树，才能让整个系统的效率最大化。
（五）什么是软件
作者从自己的认知角度再次反思什么是软件，软件的本质其实就是通过把人类的日常工作生活虚拟化，减少成本，提升单个人员的生产力，提升人类自己的利益。而软件工程师的职责在这个浪潮中，不堪重负，自然而然就分拆为不同的角色，形成了一个独特的架构体系。这一切的背后，仍然是为了提升人类自己的利益，解决人类自己的问题。
（六）不要空设架构师这个职位，给他实权。
作者在这篇博文文章中说明了架构师是什么问题，也说明了架构师的重要性。正如作者所说，架构师必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好的发挥架构师的作用，更好的把利益的调整落到实处。
（七）从架构的角度看如何写好代码
作者 Kevin 介绍了在拥有好的架构后，如何将架构落地到代码实践中，以避免代码成为系统扩展的瓶颈。文章从软件架构包含的代码架构和硬件部署架构出发，强调了代码架构的重要性，并以前文为基础，进一步探讨了如何编写合适的代码。为软件开发者提供了一种有效的代码架构设计方法，帮助开发者在项目实践中更好地实现架构的落地，提高项目的可维护性和扩展性。
(八)理清技术、业务和架构的关系
作者 Kevin 通过钻木取火的例子，深入探讨了技术、业务和架构之间的关系。文章指出，技术是为了解决业务问题而产生的，而架构则是在技术的基础上进行分拆和组合，以更高效地解决业务问题。作者强调，技术人员和业务人员应该相互理解，共同协作，才能更好地实现业务目标。
-
技术是为了解决业务问题而产生的，没有业务，技术就没有存在的前提。
-
技术与技术之间有两种关系：一是在解决同一个业务问题的前提下，更高效、更低成本的技术会淘汰低效、高成本的技术；二是一般刚开始解决根本问题的技术效率较低，然后会有提高效率的需求出现，要求改进这个技术。
-
架构是在技术的基础上进行分拆和组合，以更高效地解决业务问题。这个过程实际上是技术的进步所导致的新的架构分拆。
-
技术人员和业务人员应该相互理解，共同协作，才能更好地实现业务目标。架构师应该承担起解决业务问题的这个角色来，专注于 Business Domain 和软件本身的架构，让技术人员致力于为业务在计算机中跑起来而努力。
-
在选择技术时，应该考虑长期的成本和收益，准确识别采用什么技术的能力也是架构师所要具备的能力之一。
