怎样成长为优秀的软件架构师?( 二 )


掌控全局,就是对系统的全貌了然于胸 。从传统的建筑工程来说,建筑架构师并不单单要会画建筑图纸,而是要对地基构建、土质、材料、建筑工艺等等所有有可能影响建筑质量的因素都要了然于胸 。
掌控全局,并不是无所不能,不是成为全栈 。怎么做到掌控全局?核心在于对知识脉络的体系化梳理 。这是架构能力构建和全面提升的关键 。这种方法不单单是在软件工程中适用 。
比如学数学,我个人非常喜欢做的一件事情是自己去推导书上所有的公式 。每一个公式我都亲自推导而来 。
这样做的核心意义在于,我在尝试从0开始,去构建整个精彩纷呈的数学世界,整个数学发展史在自己的笔下重新演绎了一遍,来龙去脉清清楚楚 。有时候你甚至会推导出还没有学到的公式,但是在后面学到了 。这种体验非常有趣而又让人满足 。
是的,掌控全局的前提是:在自己心中去重新构建出整个世界 。在这个过程中,你不需要一上来沉浸在某个技术的实现细节(除非它影响了你对这个世界构建过程的理解),但是你知道整个世界的脉络,知道整个世界的骨架 。
这个时候,你对这个世界的感觉是完全不同的,因为,你已经成为了这个世界的构建者 。
而架构的本质,不也正是构建和创造么?
作为一个软件行业的从业人员,我们可能接触各种各样的技术书籍 。有讲编程语言的、讲数据结构与算法的、讲操作系统的、讲编译原理的、讲架构设计的,还有领域技术类的(比如数据库、存储、大数据、人工智能之类) 。
大部分类别的技术书,多多少少都能够找到几本经典著作 。但是,架构设计很可能是个例外,当我想推荐一本经典的架构设计书时,我并不能非常快速地想到应该推荐哪本 。
从个人经验来说,我接触过的与架构相关的图书,大概有如下这些分类 。
 

  1. 架构思维类 。这类图书通常从一些著名的架构理论讲起,比如开闭原则、单一职责原则、依赖倒置原则、接口分离原则,等等 。这种图书的问题在于过度理论化 。计算机科学归根到底属于工程技术类,实践第一 。
  2. 设计模式类 。这一类图书则一下子进入架构的局部细节,每个模式的来龙去脉并不容易理解 。就算理解了某个具体的模式,但是也很难真正做到活学活用,不知道还是不知道 。
  3. 分布式系统架构设计类 。这类图书通常从服务端的通用问题如一致性、高可用、高并发挑战等话题讲起,讲大型业务系统面临的挑战 。这些知识是非常有价值的,但无法延伸到通用业务架构,对大部分企业的架构实践并不具备真正的指导意义 。
  4. 重构类 。这类图书主要讲怎么把坏代码一步步改进到好代码 。我认为这是最实用的一类 。但在没有优秀架构师主导的情况下,大部分公司的代码不可避免地越变越坏,直到不堪重负最后不得不重写 。实际上,一个模块最初的地基是最重要的,基本决定了这座大厦能够撑多久,而重构更多侧重于大厦建成之后,在服务于人的前提下怎么去修修补补,延长生命 。
 
这些架构类的图书并没有达到我个人的期望 。因为它们都没有揭开架构设计的全貌 。
我自己在职业生涯中前后大概做过十几次的架构类演讲,这也是我最为重视、重复次数最多的一类演讲 。但同样地,这样零星的演讲对于传递架构设计思想来说,仍然远远不够 。
所以一直以来,我就心存着这样一个念头:“要写一本不一样的架构类图书” 。这个念想,也正是今天这个专栏的由来 。
这个专栏的内容组织算是我的一次尝试 。它和今天你看得到的大部分架构书并不太一样 。我基本上围绕着两个脉络主线来展开内容:
 
  1. 如何从零开始一步步构建出整个信息世界;
  2. 在整个信息世界的构建过程中,都用了哪些重要的架构思维范式,以及这些范式如何去运用于你平常的工程实践中 。
 
这两大脉络相辅相成 。首先,我们通过还原信息世界的构建过程,剥离出了整个信息世界的核心骨架,这也是最真实、最宏大的架构实践案例 。其次,我们结合这个宏大的架构实践来谈架构思维,避免因对架构思维的阐述过于理论化而让人难以理解 。
我想,每个程序员都有一颗成为架构师的心 。所以,从内容设计来说,我希望这是一个门槛最低的架构设计专栏,也希望它可以帮助到想成为架构师的初学者,达成自己的目标 。


推荐阅读