一提到架构,很多程序员可能会立刻心生敬畏,觉得这是一件很高端、很难且极具挑战的事情。然而,与编程相比,架构更多地关注宏观层面。虽然架构确实存在一些挑战,但在某些时候,架构的 “世界” 在复杂度上可能还不如编码中的细枝末节那么大。所有程序员都应尽可能早地培养自己的架构思维。即便你未来不从事架构相关工作,但拥有架构思维能极大地开拓你的视野,助力你在技术道路上走得更远。
在了解具体的架构思维培养方法之前,需先明确架构的意义究竟是什么。简单来说,架构表达的是一种关系,即多个现实元素之间的关系。这里有两个关键词:关系和现实。其中,“关系” 很好理解,指的是不同事物之间以何种形式共存。而 “现实” 却常常容易被人忽视,因为它显得很平常。但是,在做架构时,如果对某些现实的定义不精准,那么后续的工作大概率也是错误的。所以,要做好架构,第一步就是先明确当前要解决的问题或要达成的目标,并弄清楚其中涉及的相关概念所表达的业务含义。你可以将这一步中得到的相关概念用工具或者纸笔画出来,平铺开来即可。
图片
做完这一步,接下来就是传统意义上做架构的过程。对于这个过程,可以用一句话来概括:架构的过程其实就是建模的过程。所谓建模,就是进一步细化当前的事物,并基于所得信息做相关的延展和规划,循序渐进,得到一个完整的、可执行的方案的过程。
说起来容易,做起来却并不轻松。在架构的过程中,会涉及到分解、集成、复用、分层、抽象、结构化以及迭代等方面。具体该怎么做呢?可以参考以下 5 个步骤。
第一步:搞清楚要解决的现实问题。
当拿到一个稍具规模的功能后,需先弄清楚这个功能要解决的问题是什么,不要一上来就写代码或者找现成的解决方案。总是依样画葫芦的话,很难培养出自己的架构思维。
第二步:确定边界。
要考虑问题所在的场景中有哪些输入数据,最终输出的又是什么,这样就把问题的边界给定下来了。
第三步:用分解、抽象、结构化的思维来拆分问题,并梳理好每个流程。
把问题进行拆解,看看解决了哪些小问题之后,这个大问题就能被解决。然后,思考每一个小问题是否有解决方案。如果有,可以把中间的逻辑用流程图画出来。如果逻辑太复杂,那就说明设置的问题颗粒度还是太大,继续拆。如果某个小问题没有解决方案,同样继续拆,直到有解决方案为止。
第四步:借助集成、复用、分层思维给出最合理的技术实现方案,形成最终一份完整的架构。
根据自己的技术储备,针对每一个问题给出具体的技术实现方案,选择最简单、高效的一个。然后把所有问题的解决方案放在一起看,提炼可复用的部分出来,并考虑用什么形式进行封装。可以是一个简单的库,也可以是一个完整的框架,或是 API 等等。
第五步:根据对未来的预判对架构方案进行局部修正,直到合理。
根据自己对业务的理解,和与产品经理、业务方的沟通,预判一下后续可能的扩展点,看当前的设计是否能满足。如果不能满足,就逐级逆向倒推父问题,直到找到与这个新的扩展点相关的根问题,停下来把这个根问题下面的子问题全部重新设计一下。然后再重复第四步,直到得到一个当下看起来完全满足预期的方案。
整个流程下来,就完成了一次架构设计工作,这些工作可以帮助你培养自己的架构思维。等慢慢熟练之后,也可以根据实际情况自行删减一些步骤。