一提到架构，很多程序员可能会立刻心生敬畏，觉得这是一件很高端、很难且极具挑战的事情。然而，与编程相比，架构更多地关注宏观层面。虽然架构确实存在一些挑战，但在某些时候，架构的 “世界” 在复杂度上可能还不如编码中的细枝末节那么大。所有程序员都应尽可能早地培养自己的架构思维。即便你未来不从事架构相关工作，但拥有架构思维能极大地开拓你的视野，助力你在技术道路上走得更远。

在了解具体的架构思维培养方法之前，需先明确架构的意义究竟是什么。简单来说，架构表达的是一种关系，即多个现实元素之间的关系。这里有两个关键词：关系和现实。其中，“关系” 很好理解，指的是不同事物之间以何种形式共存。而 “现实” 却常常容易被人忽视，因为它显得很平常。但是，在做架构时，如果对某些现实的定义不精准，那么后续的工作大概率也是错误的。所以，要做好架构，第一步就是先明确当前要解决的问题或要达成的目标，并弄清楚其中涉及的相关概念所表达的业务含义。你可以将这一步中得到的相关概念用工具或者纸笔画出来，平铺开来即可。

图片

做完这一步，接下来就是传统意义上做架构的过程。对于这个过程，可以用一句话来概括：架构的过程其实就是建模的过程。所谓建模，就是进一步细化当前的事物，并基于所得信息做相关的延展和规划，循序渐进，得到一个完整的、可执行的方案的过程。

说起来容易，做起来却并不轻松。在架构的过程中，会涉及到分解、集成、复用、分层、抽象、结构化以及迭代等方面。具体该怎么做呢？可以参考以下 5 个步骤。

第一步：搞清楚要解决的现实问题。

当拿到一个稍具规模的功能后，需先弄清楚这个功能要解决的问题是什么，不要一上来就写代码或者找现成的解决方案。总是依样画葫芦的话，很难培养出自己的架构思维。

第二步：确定边界。

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

第三步：用分解、抽象、结构化的思维来拆分问题，并梳理好每个流程。

把问题进行拆解，看看解决了哪些小问题之后，这个大问题就能被解决。然后，思考每一个小问题是否有解决方案。如果有，可以把中间的逻辑用流程图画出来。如果逻辑太复杂，那就说明设置的问题颗粒度还是太大，继续拆。如果某个小问题没有解决方案，同样继续拆，直到有解决方案为止。

第四步：借助集成、复用、分层思维给出最合理的技术实现方案，形成最终一份完整的架构。

根据自己的技术储备，针对每一个问题给出具体的技术实现方案，选择最简单、高效的一个。然后把所有问题的解决方案放在一起看，提炼可复用的部分出来，并考虑用什么形式进行封装。可以是一个简单的库，也可以是一个完整的框架，或是 API 等等。

第五步：根据对未来的预判对架构方案进行局部修正，直到合理。

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

整个流程下来，就完成了一次架构设计工作，这些工作可以帮助你培养自己的架构思维。等慢慢熟练之后，也可以根据实际情况自行删减一些步骤。