读《架构漫谈》的一些感想

　　在阅读的《架构漫谈》，一共9篇。读之前以为的架构：架构啊，应该就是像想要盖房子一样，用木头搭起来的一个框架吧。听这名字，架构架构，多像“构造的架子”。读之后：我是谁？我在哪？架构能吃吗？

　　虽然上面的描述方法采用了夸张的修辞手法，但真实情况确实和夸张后的情况相差无几——我是真的没有读懂理解王概凯写的9篇《架构漫谈》。虽然我大可以大片大片的“引用”其中的内容，但是那样就不是我写的博客了。我一向认为既然要抄，就要全篇搬过来，但可惜《架构漫谈》没告诉人们“未经许可，随意转载”，所以我只好选择第二条路，捡自己有些明白的内容说（虽然有时候理解不代表能讲述出来）。

　　本课程全名叫做软件体系结构，我曾一度认为“软件体系结构”和“软件架构”的共同点只是“软件”和“构”。然后我就被百度噼里啪啦爆锤了一顿：二者英文名都叫做“software architecture”；二者在IEEE中的定义是相同的：一个系统的基础组织，包含各个构件、构件互相之间与环境的关系，还有指导其设计和演化的原则；“软件体系结构”一词多用于学术研究领域使用，而“软件架构”多用于工程实践领域。有篇博客比较详细的说明了二者的区别，值得一看（https://blog.csdn.net/pmlthy/article/details/1564436）。

　　有些跑题，回到《架构漫谈》中来。“软件架构”的定义众说纷纭，所以目标先放到“架构”上来：架构是规划、设计、构建的过程及最终成果。根据架构的定义，架构似乎既可以是过程，又可以是成果，这样的释义似乎有些“暧昧”。所以我们需要明白架构是如何产生的。在人类发展的过程中，由于人类单个能力的局限性和对目标（生活，工作等）的更高的要求，迫使人类之间产生互动、沟通和合作，这样就产生了架构。

　　以上，全部都是总结了《架构漫谈》中的话得到的结论。但于我而言，我依然没有弄明白架构的意思。但好在得益于百度的强大功能，我通过查阅资料，结合《架构漫谈》，得到了我个人比较能接受理解的软件架构含义（土话版）：一个软件系统可以根据某种规则（功能、模块、子系统）进行切分，切出来的部分之间的联系是有效的，而他们的合并，则可以满足系统的目标要求，而架构，则是指挥他们或独立工作或协作工作，最终完成系统目标的顶层设计。

　　接下来，《架构漫谈》说到了架构师的作用，在一般的XX师中，比如老师，作用是解决问题（笑）。但《架构漫谈》的作者却提出，架构师的作用不是解决问题，而是找到问题。并且提出了一句很有意思的话：……如果是真正的问题的话，提问题过来的人肯定都能够自己解决了，不需要找架构师……这让我的三观受到了极大地冲击——我要是能自己解决问题，还用得着问别人吗？但接着读下去，我思考之后认为，作者首先将“真正的问题都不是问题”作为前提，那么就得到了上面那句话，既然问到架构师头上了，那么就说明这个“问题”不是是一个“真正的问题”，所以就引出了作者的结论：提出问题的人没有提出真正的问题，而架构师的作用，就是“识别出真正的问题”然后交给提出问题的人，让他自己解决真正的问题。

　　以上，就是我读《架构漫谈》中的一部分问题和联想。

扩展阅读：

　　《从零开始学架构》 作者：李运华

　　软件体系结构与软件架构解析 作者：pmlthy