gitbook/许式伟的架构课/docs/166014.md
2022-09-03 22:05:03 +08:00

10 KiB
Raw Blame History

57 | 心性:架构师的修炼之道

你好,我是七牛云许式伟。

今天开始,我们终于进入第五章,也就是大家常规认为的架构课的内容:架构思维篇。

怎么还没有谈架构?这可能是很多人心中的疑问。这个问题我们今天后面会给出它的答案。

但是我相信所有的读者最关心的一个问题无疑是:

怎么成为优秀的架构师?架构师的修炼之道究竟是什么?

我的答案是:修心。

心性,是架构师区别于一般软件工程师的地方。也是为什么他能够看到那么多人看不到的关键点的原因。

同理心的修炼:认同他人的能力

在前面几个章节,我们已经陆续介绍了架构的全过程:

但架构师面临的问题往往是错综复杂的。

给你一个明确的需求说明文档,干干净净地从头开始做 “需求分析”,做 “概要设计”,做模块的 “详细设计”,最后编码实现,这是理想场景。

现实中,大多数情况并不是这样。而是:你拿到了一份长长的源代码,加上少得可怜的几份过时文档。然后被安排做一个新功能,或者改一个顽固 Bug。

你接手的代码量,比前面我们架构实战案例 “画图程序” 长得多,动辄几百万甚至上千万行的源代码。文档也要少得多,没有清晰的网络协议和接口文档,更别提详细设计文档。有句程序员界的名言:“程序员最讨厌的两件事情:一件事情是写文档,一件事情是接手的代码发现没文档”。这是很真实的对现实的写照。

我知道对于 “画图程序” 这个案例,一些读者会说:怎么一上来就给我这么复杂的实战案例,就不能循序渐进一点么?

但它真的已经是最小的架构案例了,不到一千行的代码规模。相比在现实中你不得不面对几百万甚至上千万行的代码规模的工程,这只是小菜一碟。

下一章的 “软件工程篇”,我们会探讨怎么阅读别人的源代码。现在我们还是先回归到真实的场景:给一个几百万甚至上千万行的工程项目增加一个新功能,修改一个顽固 Bug或者心一横做重构。

问题是:你真的是在改善系统,还是在破坏系统?

很多时候,你是在破坏系统。代码为什么会散发臭味?就是因为有很多很多缺乏良好架构思维能力的工程师在加功能,在做重构。

我说的不太客气。但需要认清的一点是,这就是绝大部分公司面临的现实问题。

最值得研究的是重构。重构不为改善用户体验,它的目标是为了改善系统质量,清除代码中的臭味。但现实中也有不小比例的重构实际上是在让问题变得更糟糕。

为什么会这样?

因为,这里有工程师发展成为架构师所需要的最重要的心性修炼:

认同他人的能力。

架构师最重要的是有同理心,要有认同他人的能力。不要在没有全面理解他人思想的情况下去调整既有代码的设计逻辑。

读懂他人的思想。

这很难。所以,如果真冲着读懂他人思想的目标去,接手一个模块刚开始往往会比较慢,具体需要花多久取决于你的经验积累。

理解一个系统的架构,如果当初做这个系统的几个核心人员你还联系得上,那么不要犹豫,争取一个小时的时间和他们做沟通。这比你直接一上来就啃代码要好。纯啃代码就好比做逆向工程把机器码转回源代码,是一件非常复杂的事情。

但是如果联系不到人,就只能老老实实去啃代码。结合文档看代码往往会事半功倍,但也要注意识别出文档和代码不一致的情形,把它们记录下来。

经验积累得多了,看到源代码就能很快体会别人的思想。这背后所依赖的,其实也是架构能力。架构师往往对一个需求场景会有多条实现路径的思考和评估。这样的思考和评估做多了,看到别人的代码就容易建立熟悉感,一眼看出别人的思路是什么。

架构师的同理心,也体现在需求分析上。

这在某种意义上来说是更难的一件事情。因为,接管系统的时候要了解的是其他架构师的思想,它毕竟是你熟悉的场景。而需求分析则是理清用户需求的能力,你需要代入用户,理解用户的核心诉求。所以需求分析需要更强的空杯心态,去认同他人。

全局观的修炼:保持好奇心与韧性

架构师第二大能力,是全局观的修炼。没有了全貌,那就是井底之蛙,谈何架构?

为什么我们的架构课不是一上来就谈架构思维?

这是因为,并不是我们理解了架构思维的原则,就能够做好架构。

架构之道,是虚实结合之道。

我们要理论与实践相结合。不可能只要理论,否则架构师满天飞了。如果两者只能取其一,我选实践。

从实悟虚,从虚就实,运用得当方得升华。这其实是最朴素的虚实结合的道理。对学架构来说尤其如此。架构思维的感悟并不能一步到位,永远有进步的空间,需要我们在不断实践中感悟,升华自己的认知。

架构课内容的前四章为 “基础平台”、“桌面开发”、“服务端开发”、“服务治理”。

从内容上来说,由 “基础平台(硬件架构/编程语言/操作系统)”,到 “业务开发(桌面开发/服务端开发)”,再到 “业务治理(服务治理/技术支持/用户增长)”,基本上覆盖了信息技术主体骨架的各个方面。

有了骨架,就有了全貌,有了全局的视角。

前面四章,我们内容体系的侧重点放在了架构演变的过程。我们研究什么东西在迭代。这样,我们就不是去学习一个 “静态的”、“不变的” 信息技术的骨架,更重要的是我们也在学信息技术的发展历史。

有了基础平台,有了前端与后端,有了过去与未来,我们就有了真真正正的全貌。

我们博览群书,为的就是不拘于一隅,串联我们自身的知识体系,形成我们的认知框架。

这很难。

很多人都有关于 “广度” 与 “深度” 的辩证与困惑。全局观这件事情,对于心性上的修炼,比的是好奇心与韧性。

保持对这个世界的好奇心。看到新科技与新思想,先认同它,去体会它,理解它产生的需求背景与技术脉络,以此融入自己的知识体系。

持续地学习。

架构师需要有学习韧性。但并不是所有的技术都值得深耕。我们也都没有这个精力去这么做。我们要做到的是,随时想深入耕耘就能深入。

怎么深耕,更多的是结合自己的工作内容和兴趣。很多工程师会有困惑,觉得自己的工作内容平淡无奇,没法让自己进步,但实际上瓶颈不在于工作内容,在于自己心性的修炼。

好的架构师,拥有化腐朽为神奇的能力。

迭代能力的修炼:学会否定自己

架构师第三大能力的修炼,是迭代,是反思,是自我批判。

不管你喜不喜欢,工程师天天都在接任务,码代码。但是差别在于,你究竟在用什么样的态度来接任务,码代码。

关于码代码,不少优秀的工程师都有这样的体会:洋洋洒洒写了好多代码,过了半年一年,自己看着怎么看怎么不爽。

如果你有同感,那么恭喜你:你进步了。

但,接下来的事情更重要。

你是捏着鼻子忍着,继续接老板安排下来的新任务;还是,百忙里抽出一点时间,把之前写的代码改到你满意的样子。

这个改代码的过程,它之所以重要,是因为它才是真真正正的架构能力升华的过程。

通过迭代而升华。这是架构能力提升之路。你的收益不会只是你重构的那一个模块本身。通过重构,你建立了新的知识体系。它是内在根本性的变化,看不见但你自己可以体会得到。

接任务的态度也很重要。

面对每一个新的开发任务,都是一次重新审视架构合理性的机会。

就算这个模块从来没有交给过他人,所有代码都是你自己写的,也不代表这个模块就不会老化,发出臭味。这里面的原因在于,很多时候你给模块加上新功能的时候,往往会出现很多当初架构没有考虑到的场景,导致不得不用打补丁的方式把需求给满足了。

一个需求捏着鼻子做,两个需求捏着鼻子做,慢慢的系统就不堪重负,变得很脆弱,到后面加功能就会变得越来越困难。

所以,发现架构无法很方便地支持某个需求,就意味着架构存在缺陷,这时要及时停下来思考以下问题:

  • 还有哪些潜在的需求,现在还没有收到,但是未来可能会需要去满足?
  • 如果这些需求当初就提出来了,架构做成什么样更合理一些?
  • 当前的架构设计,迭代到新架构设计,它的成本是什么样的?

在架构调整这件事情上,早迭代,小步迭代,比做一个大的重构版本要好。

结语

架构师成长之旅,是心性修炼之旅。我们需要记得,并不是理解了架构思维的原则,就能够做好架构。

架构之道,是虚实结合之道。理论与实践相结合。

从实悟虚,从虚就实,运用得当方得升华。架构思维的感悟并不能一步到位,永远有进步的空间,需要我们在不断实践中感悟,升华自己的认知。

从技能来说,我们可能把架构师能力去归结为:

  • 理需求的能力;
  • 读代码的能力;
  • 抽象系统的能力。

但是架构师修炼之道,更难的是在心性上,这包括:

  • 同理心的修炼,认同他人的能力。
  • 全局观的修炼,保持好奇心和学习的韧性。
  • 迭代能力的修炼,学会反思,学会在自我否定中不断成长。

如果你对今天的内容有什么思考与解读,欢迎给我留言,我们一起讨论。下一讲我们聊聊 “如何判断架构设计的优劣”。

如果你觉得有所收获,也欢迎把文章分享给你的朋友。感谢你的收听,我们下期再见。