167 lines
10 KiB
Markdown
167 lines
10 KiB
Markdown
# 57 | 心性：架构师的修炼之道
|
||
|
||
你好，我是七牛云许式伟。
|
||
|
||
今天开始，我们终于进入第五章，也就是大家常规认为的架构课的内容：架构思维篇。
|
||
|
||
怎么还没有谈架构？这可能是很多人心中的疑问。这个问题我们今天后面会给出它的答案。
|
||
|
||
但是我相信所有的读者最关心的一个问题无疑是：
|
||
|
||
怎么成为优秀的架构师？架构师的修炼之道究竟是什么？
|
||
|
||
我的答案是：修心。
|
||
|
||
心性，是架构师区别于一般软件工程师的地方。也是为什么他能够看到那么多人看不到的关键点的原因。
|
||
|
||
## 同理心的修炼：认同他人的能力
|
||
|
||
在前面几个章节，我们已经陆续介绍了架构的全过程：
|
||
|
||
* [17 | 架构：需求分析 (上)](https://time.geekbang.org/column/article/100140)
|
||
* [18 | 架构：需求分析（下）-实战案例](https://time.geekbang.org/column/article/100930)
|
||
* [32 | 架构：系统的概要设计](https://time.geekbang.org/column/article/117783)
|
||
* [45 | 架构：怎么做详细设计？](https://time.geekbang.org/column/article/142032)
|
||
|
||
但架构师面临的问题往往是错综复杂的。
|
||
|
||
给你一个明确的需求说明文档，干干净净地从头开始做 “需求分析”，做 “概要设计”，做模块的 “详细设计”，最后编码实现，这是理想场景。
|
||
|
||
现实中，大多数情况并不是这样。而是：你拿到了一份长长的源代码，加上少得可怜的几份过时文档。然后被安排做一个新功能，或者改一个顽固 Bug。
|
||
|
||
你接手的代码量，比前面我们架构实战案例 “画图程序” 长得多，动辄几百万甚至上千万行的源代码。文档也要少得多，没有清晰的网络协议和接口文档，更别提详细设计文档。有句程序员界的名言：“程序员最讨厌的两件事情：一件事情是写文档，一件事情是接手的代码发现没文档”。这是很真实的对现实的写照。
|
||
|
||
我知道对于 “画图程序” 这个案例，一些读者会说：怎么一上来就给我这么复杂的实战案例，就不能循序渐进一点么？
|
||
|
||
但它真的已经是最小的架构案例了，不到一千行的代码规模。相比在现实中你不得不面对几百万甚至上千万行的代码规模的工程，这只是小菜一碟。
|
||
|
||
下一章的 “软件工程篇”，我们会探讨怎么阅读别人的源代码。现在我们还是先回归到真实的场景：给一个几百万甚至上千万行的工程项目增加一个新功能，修改一个顽固 Bug，或者心一横做重构。
|
||
|
||
问题是：你真的是在改善系统，还是在破坏系统？
|
||
|
||
很多时候，你是在破坏系统。代码为什么会散发臭味？就是因为有很多很多缺乏良好架构思维能力的工程师在加功能，在做重构。
|
||
|
||
我说的不太客气。但需要认清的一点是，这就是绝大部分公司面临的现实问题。
|
||
|
||
最值得研究的是重构。重构不为改善用户体验，它的目标是为了改善系统质量，清除代码中的臭味。但现实中也有不小比例的重构实际上是在让问题变得更糟糕。
|
||
|
||
为什么会这样？
|
||
|
||
因为，这里有工程师发展成为架构师所需要的最重要的心性修炼：
|
||
|
||
> 认同他人的能力。
|
||
|
||
架构师最重要的是有同理心，要有认同他人的能力。不要在没有全面理解他人思想的情况下去调整既有代码的设计逻辑。
|
||
|
||
读懂他人的思想。
|
||
|
||
这很难。所以，如果真冲着读懂他人思想的目标去，接手一个模块刚开始往往会比较慢，具体需要花多久取决于你的经验积累。
|
||
|
||
理解一个系统的架构，如果当初做这个系统的几个核心人员你还联系得上，那么不要犹豫，争取一个小时的时间和他们做沟通。这比你直接一上来就啃代码要好。纯啃代码就好比做逆向工程把机器码转回源代码，是一件非常复杂的事情。
|
||
|
||
但是如果联系不到人，就只能老老实实去啃代码。结合文档看代码往往会事半功倍，但也要注意识别出文档和代码不一致的情形，把它们记录下来。
|
||
|
||
经验积累得多了，看到源代码就能很快体会别人的思想。这背后所依赖的，其实也是架构能力。架构师往往对一个需求场景会有多条实现路径的思考和评估。这样的思考和评估做多了，看到别人的代码就容易建立熟悉感，一眼看出别人的思路是什么。
|
||
|
||
架构师的同理心，也体现在需求分析上。
|
||
|
||
这在某种意义上来说是更难的一件事情。因为，接管系统的时候要了解的是其他架构师的思想，它毕竟是你熟悉的场景。而需求分析则是理清用户需求的能力，你需要代入用户，理解用户的核心诉求。所以需求分析需要更强的空杯心态，去认同他人。
|
||
|
||
## 全局观的修炼：保持好奇心与韧性
|
||
|
||
架构师第二大能力，是全局观的修炼。没有了全貌，那就是井底之蛙，谈何架构？
|
||
|
||
为什么我们的架构课不是一上来就谈架构思维？
|
||
|
||
这是因为，并不是我们理解了架构思维的原则，就能够做好架构。
|
||
|
||
架构之道，是虚实结合之道。
|
||
|
||
我们要理论与实践相结合。不可能只要理论，否则架构师满天飞了。如果两者只能取其一，我选实践。
|
||
|
||
从实悟虚，从虚就实，运用得当方得升华。这其实是最朴素的虚实结合的道理。对学架构来说尤其如此。架构思维的感悟并不能一步到位，永远有进步的空间，需要我们在不断实践中感悟，升华自己的认知。
|
||
|
||
架构课内容的前四章为 “基础平台”、“桌面开发”、“服务端开发”、“服务治理”。
|
||
|
||
从内容上来说，由 “基础平台（硬件架构/编程语言/操作系统）”，到 “业务开发（桌面开发/服务端开发）”，再到 “业务治理（服务治理/技术支持/用户增长）”，基本上覆盖了信息技术主体骨架的各个方面。
|
||
|
||
有了骨架，就有了全貌，有了全局的视角。
|
||
|
||
前面四章，我们内容体系的侧重点放在了架构演变的过程。我们研究什么东西在迭代。这样，我们就不是去学习一个 “静态的”、“不变的” 信息技术的骨架，更重要的是我们也在学信息技术的发展历史。
|
||
|
||
有了基础平台，有了前端与后端，有了过去与未来，我们就有了真真正正的全貌。
|
||
|
||
我们博览群书，为的就是不拘于一隅，串联我们自身的知识体系，形成我们的认知框架。
|
||
|
||
这很难。
|
||
|
||
很多人都有关于 “广度” 与 “深度” 的辩证与困惑。全局观这件事情，对于心性上的修炼，比的是好奇心与韧性。
|
||
|
||
保持对这个世界的好奇心。看到新科技与新思想，先认同它，去体会它，理解它产生的需求背景与技术脉络，以此融入自己的知识体系。
|
||
|
||
持续地学习。
|
||
|
||
架构师需要有学习韧性。但并不是所有的技术都值得深耕。我们也都没有这个精力去这么做。我们要做到的是，随时想深入耕耘就能深入。
|
||
|
||
怎么深耕，更多的是结合自己的工作内容和兴趣。很多工程师会有困惑，觉得自己的工作内容平淡无奇，没法让自己进步，但实际上瓶颈不在于工作内容，在于自己心性的修炼。
|
||
|
||
好的架构师，拥有化腐朽为神奇的能力。
|
||
|
||
## 迭代能力的修炼：学会否定自己
|
||
|
||
架构师第三大能力的修炼，是迭代，是反思，是自我批判。
|
||
|
||
不管你喜不喜欢，工程师天天都在接任务，码代码。但是差别在于，你究竟在用什么样的态度来接任务，码代码。
|
||
|
||
关于码代码，不少优秀的工程师都有这样的体会：洋洋洒洒写了好多代码，过了半年一年，自己看着怎么看怎么不爽。
|
||
|
||
如果你有同感，那么恭喜你：你进步了。
|
||
|
||
但，接下来的事情更重要。
|
||
|
||
你是捏着鼻子忍着，继续接老板安排下来的新任务；还是，百忙里抽出一点时间，把之前写的代码改到你满意的样子。
|
||
|
||
这个改代码的过程，它之所以重要，是因为它才是真真正正的架构能力升华的过程。
|
||
|
||
通过迭代而升华。这是架构能力提升之路。你的收益不会只是你重构的那一个模块本身。通过重构，你建立了新的知识体系。它是内在根本性的变化，看不见但你自己可以体会得到。
|
||
|
||
接任务的态度也很重要。
|
||
|
||
面对每一个新的开发任务，都是一次重新审视架构合理性的机会。
|
||
|
||
就算这个模块从来没有交给过他人，所有代码都是你自己写的，也不代表这个模块就不会老化，发出臭味。这里面的原因在于，很多时候你给模块加上新功能的时候，往往会出现很多当初架构没有考虑到的场景，导致不得不用打补丁的方式把需求给满足了。
|
||
|
||
一个需求捏着鼻子做，两个需求捏着鼻子做，慢慢的系统就不堪重负，变得很脆弱，到后面加功能就会变得越来越困难。
|
||
|
||
所以，发现架构无法很方便地支持某个需求，就意味着架构存在缺陷，这时要及时停下来思考以下问题：
|
||
|
||
* 还有哪些潜在的需求，现在还没有收到，但是未来可能会需要去满足？
|
||
* 如果这些需求当初就提出来了，架构做成什么样更合理一些？
|
||
* 当前的架构设计，迭代到新架构设计，它的成本是什么样的？
|
||
|
||
在架构调整这件事情上，早迭代，小步迭代，比做一个大的重构版本要好。
|
||
|
||
## 结语
|
||
|
||
架构师成长之旅，是心性修炼之旅。我们需要记得，并不是理解了架构思维的原则，就能够做好架构。
|
||
|
||
架构之道，是虚实结合之道。理论与实践相结合。
|
||
|
||
从实悟虚，从虚就实，运用得当方得升华。架构思维的感悟并不能一步到位，永远有进步的空间，需要我们在不断实践中感悟，升华自己的认知。
|
||
|
||
从技能来说，我们可能把架构师能力去归结为：
|
||
|
||
* 理需求的能力；
|
||
* 读代码的能力；
|
||
* 抽象系统的能力。
|
||
|
||
但是架构师修炼之道，更难的是在心性上，这包括：
|
||
|
||
* 同理心的修炼，认同他人的能力。
|
||
* 全局观的修炼，保持好奇心和学习的韧性。
|
||
* 迭代能力的修炼，学会反思，学会在自我否定中不断成长。
|
||
|
||
如果你对今天的内容有什么思考与解读，欢迎给我留言，我们一起讨论。下一讲我们聊聊 “如何判断架构设计的优劣”。
|
||
|
||
如果你觉得有所收获，也欢迎把文章分享给你的朋友。感谢你的收听，我们下期再见。
|
||
|