架构思维其实就那么回事-技术圈

这里是Z哥的个人公众号

每周五11：45 按时送达

当然了，也会时不时加个餐～

我的第「153」篇原创敬上

一提到架构，对于工作经验不多的小伙伴来说会心生敬畏之心。觉得是一个很高端、很难、很有挑战的事情。

没错，架构不像我们平时的coding工作，这是一个宏观层面的事情。而对我们内心来说，越宏观、越大的东西，我们总会觉得更不容易控制，所以会心生敬畏。但实际上，架构的“世界”在复杂度上可能还不如coding上的细枝末节那么大。

我有幸从2015年开始接触架构相关的工作，作为过来人，我建议所有程序员们尽可能早地培养自己的架构思维，这对你未来在技术路线上走的更远很有帮助。

因为这是一个视野问题。同一个功能，代码的实现方式可以有千千万，每一次coding就是一次决策。你在视野10米内做决策，自然没有在1000米范围内做出的决策来得更优。

架构思维的培养并不需要你非得是架构师，每个程序员都可以。下面我来分享一个大家都能尝试的方法。

首先，心里一定要清楚「架构的意义」是什么？并且一直带着这个意义做接下去的事情。否则很容易本末倒置甚至是跑偏。

Z哥对架构意义的理解是：架构表达的是一种关系，是多个现实元素之间的关系。

这里面的两个关键词是「关系」和「现实」。「关系」很好理解，就是不同事物之间以什么样的形式共存。而「现实」容易被人轻视，因为它显得很平常，但是往往我们在做架构的时候，对于某些现实的定义是不精准的。现实定义错了，后面的工作大概率也是错的。

所以，要做的第一件事就出来了：明确你当前要解决的问题，或者要达成的目标。并且弄清楚其中涉及到的相关概念所表达的业务含义。

你可以将这一步中所得到的相关概念用工具或者纸笔画出来，平铺开来就可以。比如像下面这样。

做完了这一步，接下来就是传统意义上做架构的过程。对于这个过程，也用一句话来概括就是：架构的过程其实就是建模的过程。

没错，「建模」就是进一步细化当前的事物，并且基于所得的信息做相关的延展和规划，循序渐进，得到一个完整的、可执行的方案的过程。

说起来很简单，做起来却不那么简单。在这个过程中会涉及到以下一些思维方向：

那么具体怎么做呢？

Z哥建议你可以先按照以下的步骤来进行。

在你熟练后，可以根据实际情况自行删减一些步骤。下面我来展开说一下。

拿到一个稍具规模（小于一周的功能发挥空间就很小了）的功能后，首先先弄清楚“这个功能要解决的问题是什么？”。不要上来就写代码或者找现成的解决方案。首先不说质量如何，如果总是走一步算一步或者依样画葫芦如何能锻炼架构思维呢？

考虑问题所在的场景中有哪些输入数据，最终输出的又是什么。这样就把问题的边界给定下来了。

把问题进行拆解，看看解决了哪些小问题之后，这个问题就能被解决。这个过程中再做前面提到的，把其中的相关概念在纸上画出来。

然后，再思考每一个小问题你是否有解决方案。如果有，那么把中间的逻辑用流程图画出来。如果逻辑太复杂，说明问题的颗粒度还是太大，继续拆。如果某个小问题没有解决方案同样继续拆，直到有解决方案为止。

最终形成的一个个针对每个小问题的流程图，就是你初步的架构设计。

这个环节主要发挥你的分解、抽象、结构化的思维。

根据你的技术储备，针对每一个问题给出具体的技术实现方案，选择你认为最简单、高效的一个即可。

然后把所有问题的解决方案放在一起看，提炼可复用的部分出来，并考虑用什么形式进行封装。可以是一个简单的库，也可以是一个完整的框架，或是API等等。

这个环节主要发挥你的集成、复用、分层思维。

还没完。

根据你对业务理解和与产品经理、业务方的沟通，预判一下后续可能的扩展点，看当前的设计是否能满足。如果不能满足，逐级逆向倒推父问题，直到找到与这个新的扩展点相关的根问题，停下来把这个根问题下面的子问题全部重新设计一下。

再重复第4步，直到得到一个当下看起来完全满足预期的方案。至此，你就完成了一次架构设计工作。

切记，变更尽量从根问题开始调整，而不是从最近的问题开始。因为选择后者容易积累技术债务。

最后，还是那句话。架构是迭代出来的，一次性拆分刚好能恰到好处几乎是不可能的。

如果你想成为一位优秀的架构师，那么画架构图的技能也需要专门学习一下。架构图的种类有很多，常见的类型我之前做过整理，你可以参考一下：《软件开发中会用到的图》。

好了，总结一下。

这篇呢Z哥和你分享了什么是架构思维，以及如何来培养架构思维。

主要分为以下5步。

希望对你有所启发。既然都看到这了，你肯定很想成为架构师，祝愿你早日成功。