这里是Z哥的个人公众号
每周五11:45 按时送达
当然了,也会时不时加个餐~
我的第「153」篇原创敬上
一提到架构,对于工作经验不多的小伙伴来说会心生敬畏之心。觉得是一个很高端、很难、很有挑战的事情。
没错,架构不像我们平时的coding工作,这是一个宏观层面的事情。而对我们内心来说,越宏观、越大的东西,我们总会觉得更不容易控制,所以会心生敬畏。但实际上,架构的“世界”在复杂度上可能还不如coding上的细枝末节那么大。
我有幸从2015年开始接触架构相关的工作,作为过来人,我建议所有程序员们尽可能早地培养自己的架构思维,这对你未来在技术路线上走的更远很有帮助。
因为这是一个视野问题。同一个功能,代码的实现方式可以有千千万,每一次coding就是一次决策。你在视野10米内做决策,自然没有在1000米范围内做出的决策来得更优。
架构思维的培养并不需要你非得是架构师,每个程序员都可以。下面我来分享一个大家都能尝试的方法。
首先,心里一定要清楚「架构的意义」是什么?并且一直带着这个意义做接下去的事情。否则很容易本末倒置甚至是跑偏。
Z哥对架构意义的理解是:架构表达的是一种关系,是多个现实元素之间的关系。
这里面的两个关键词是「关系」和「现实」。「关系」很好理解,就是不同事物之间以什么样的形式共存。而「现实」容易被人轻视,因为它显得很平常,但是往往我们在做架构的时候,对于某些现实的定义是不精准的。现实定义错了,后面的工作大概率也是错的。
所以,要做的第一件事就出来了:明确你当前要解决的问题,或者要达成的目标。并且弄清楚其中涉及到的相关概念所表达的业务含义。
你可以将这一步中所得到的相关概念用工具或者纸笔画出来,平铺开来就可以。比如像下面这样。
做完了这一步,接下来就是传统意义上做架构的过程。对于这个过程,也用一句话来概括就是:架构的过程其实就是建模的过程。
没错,「建模」就是进一步细化当前的事物,并且基于所得的信息做相关的延展和规划,循序渐进,得到一个完整的、可执行的方案的过程。
说起来很简单,做起来却不那么简单。在这个过程中会涉及到以下一些思维方向:
- 分解。一个复杂的概念如何通过分解变得更容易理解和控制。
- 集成。多个模型之间以什么样的技术方案“沟通”。
- 复用。哪些模型之间有较高重合度,可以将重合部分单独建模重复利用。
- 分层。这就是「高内聚低耦合」思想的体现,为了让项目更加的井然有序,将职责类似的模型归纳到同一个“层”里。
- 抽象。将模糊不清的概念进行提炼,让其表现得更加通用,降低复杂度。
- 结构化。这是一种系统化的决策思维。比如你可以将信息通过二维表或者树型来陈列,然后就能发现其中隐含的一些关系,帮助你决策。
- 迭代。抛弃完美主义,寻求“合适”。因为那些现在看起来优秀的架构,都是慢慢迭代出来的。
那么具体怎么做呢?
Z哥建议你可以先按照以下的步骤来进行。
- 搞清楚要解决的现实问题。
- 确定边界。
- 用分解、抽象、结构化的思维来拆分问题并梳理好每个流程。
- 借助集成、复用、分层思维给出你认为最合理的技术实现方案。形成最终一份完整的架构。
- 根据对未来的预判对架构方案进行局部修正,直到合理。
在你熟练后,可以根据实际情况自行删减一些步骤。下面我来展开说一下。
01
拿到一个稍具规模(小于一周的功能发挥空间就很小了)的功能后,首先先弄清楚“这个功能要解决的问题是什么?”。不要上来就写代码或者找现成的解决方案。首先不说质量如何,如果总是走一步算一步或者依样画葫芦如何能锻炼架构思维呢?
02
考虑问题所在的场景中有哪些输入数据,最终输出的又是什么。这样就把问题的边界给定下来了。
03
把问题进行拆解,看看解决了哪些小问题之后,这个问题就能被解决。这个过程中再做前面提到的,把其中的相关概念在纸上画出来。
然后,再思考每一个小问题你是否有解决方案。如果有,那么把中间的逻辑用流程图画出来。如果逻辑太复杂,说明问题的颗粒度还是太大,继续拆。如果某个小问题没有解决方案同样继续拆,直到有解决方案为止。
最终形成的一个个针对每个小问题的流程图,就是你初步的架构设计。
这个环节主要发挥你的分解、抽象、结构化的思维。
04
根据你的技术储备,针对每一个问题给出具体的技术实现方案,选择你认为最简单、高效的一个即可。
然后把所有问题的解决方案放在一起看,提炼可复用的部分出来,并考虑用什么形式进行封装。可以是一个简单的库,也可以是一个完整的框架,或是API等等。
这个环节主要发挥你的集成、复用、分层思维。
还没完。
05
根据你对业务理解和与产品经理、业务方的沟通,预判一下后续可能的扩展点,看当前的设计是否能满足。如果不能满足,逐级逆向倒推父问题,直到找到与这个新的扩展点相关的根问题,停下来把这个根问题下面的子问题全部重新设计一下。
再重复第4步,直到得到一个当下看起来完全满足预期的方案。至此,你就完成了一次架构设计工作。
切记,变更尽量从根问题开始调整,而不是从最近的问题开始。因为选择后者容易积累技术债务。
最后,还是那句话。架构是迭代出来的,一次性拆分刚好能恰到好处几乎是不可能的。
如果你想成为一位优秀的架构师,那么画架构图的技能也需要专门学习一下。架构图的种类有很多,常见的类型我之前做过整理,你可以参考一下:《软件开发中会用到的图》。
好了,总结一下。
这篇呢Z哥和你分享了什么是架构思维,以及如何来培养架构思维。
主要分为以下5步。
- 搞清楚要解决的现实问题。
- 确定边界。
- 用分解、抽象、结构化的思维来拆分问题并梳理好每个流程。
- 借助集成、复用、分层思维给出你认为最合理的技术实现方案。形成最终一份完整的架构。
- 根据对未来的预判对架构方案进行局部修正,直到合理。
希望对你有所启发。既然都看到这了,你肯定很想成为架构师,祝愿你早日成功。
原创文章,转载请注明本文链接: https://zacharyfan.com/archives/1265.html
关于作者:张帆(Zachary,个人微信号:Zachary-ZF)。坚持用心打磨每一篇高质量原创。欢迎扫描二维码~
定期发表原创内容:架构设计丨分布式系统丨产品丨运营丨一些思考。
如果你是初级程序员,想提升但不知道如何下手。又或者做程序员多年,陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」,回复「技术」,送你一份我长期收集和整理的思维导图。
如果你是运营,面对不断变化的市场束手无策。又或者想了解主流的运营策略,以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」,回复「运营」,送你一份我长期收集和整理的思维导图。