57 | 心性：架构师的修炼之道
下载APP
关闭
渠道合作
推荐作者
57 | 心性：架构师的修炼之道
2019-11-15 许式伟 来自北京
《许式伟的架构课》
课程介绍
讲述：丁伟
时长11:27大小10.46M
你好，我是七牛云许式伟。
今天开始，我们终于进入第五章，也就是大家常规认为的架构课的内容：架构思维篇。
怎么还没有谈架构？这可能是很多人心中的疑问。这个问题我们今天后面会给出它的答案。
但是我相信所有的读者最关心的一个问题无疑是：
怎么成为优秀的架构师？架构师的修炼之道究竟是什么？
我的答案是：修心。
心性，是架构师区别于一般软件工程师的地方。也是为什么他能够看到那么多人看不到的关键点的原因。
同理心的修炼：认同他人的能力
在前面几个章节，我们已经陆续介绍了架构的全过程：
但架构师面临的问题往往是错综复杂的。
给你一个明确的需求说明文档，干干净净地从头开始做 “需求分析”，做 “概要设计”，做模块的 “详细设计”，最后编码实现，这是理想场景。
现实中，大多数情况并不是这样。而是：你拿到了一份长长的源代码，加上少得可怜的几份过时文档。然后被安排做一个新功能，或者改一个顽固 Bug。
你接手的代码量，比前面我们架构实战案例 “画图程序” 长得多，动辄几百万甚至上千万行的源代码。文档也要少得多，没有清晰的网络协议和接口文档，更别提详细设计文档。有句程序员界的名言：“程序员最讨厌的两件事情：一件事情是写文档，一件事情是接手的代码发现没文档”。这是很真实的对现实的写照。
我知道对于 “画图程序” 这个案例，一些读者会说：怎么一上来就给我这么复杂的实战案例，就不能循序渐进一点么？
但它真的已经是最小的架构案例了，不到一千行的代码规模。相比在现实中你不得不面对几百万甚至上千万行的代码规模的工程，这只是小菜一碟。
下一章的 “软件工程篇”，我们会探讨怎么阅读别人的源代码。现在我们还是先回归到真实的场景：给一个几百万甚至上千万行的工程项目增加一个新功能，修改一个顽固 Bug，或者心一横做重构。
问题是：你真的是在改善系统，还是在破坏系统？
很多时候，你是在破坏系统。代码为什么会散发臭味？就是因为有很多很多缺乏良好架构思维能力的工程师在加功能，在做重构。
我说的不太客气。但需要认清的一点是，这就是绝大部分公司面临的现实问题。
最值得研究的是重构。重构不为改善用户体验，它的目标是为了改善系统质量，清除代码中的臭味。但现实中也有不小比例的重构实际上是在让问题变得更糟糕。
为什么会这样？
因为，这里有工程师发展成为架构师所需要的最重要的心性修炼：
认同他人的能力。
架构师最重要的是有同理心，要有认同他人的能力。不要在没有全面理解他人思想的情况下去调整既有代码的设计逻辑。
读懂他人的思想。
这很难。所以，如果真冲着读懂他人思想的目标去，接手一个模块刚开始往往会比较慢，具体需要花多久取决于你的经验积累。
理解一个系统的架构，如果当初做这个系统的几个核心人员你还联系得上，那么不要犹豫，争取一个小时的时间和他们做沟通。这比你直接一上来就啃代码要好。纯啃代码就好比做逆向工程把机器码转回源代码，是一件非常复杂的事情。
但是如果联系不到人，就只能老老实实去啃代码。结合文档看代码往往会事半功倍，但也要注意识别出文档和代码不一致的情形，把它们记录下来。
经验积累得多了，看到源代码就能很快体会别人的思想。这背后所依赖的，其实也是架构能力。架构师往往对一个需求场景会有多条实现路径的思考和评估。这样的思考和评估做多了，看到别人的代码就容易建立熟悉感，一眼看出别人的思路是什么。
架构师的同理心，也体现在需求分析上。
这在某种意义上来说是更难的一件事情。因为，接管系统的时候要了解的是其他架构师的思想，它毕竟是你熟悉的场景。而需求分析则是理清用户需求的能力，你需要代入用户，理解用户的核心诉求。所以需求分析需要更强的空杯心态，去认同他人。
全局观的修炼：保持好奇心与韧性
架构师第二大能力，是全局观的修炼。没有了全貌，那就是井底之蛙，谈何架构？
为什么我们的架构课不是一上来就谈架构思维？
这是因为，并不是我们理解了架构思维的原则，就能够做好架构。
架构之道，是虚实结合之道。
我们要理论与实践相结合。不可能只要理论，否则架构师满天飞了。如果两者只能取其一，我选实践。
从实悟虚，从虚就实，运用得当方得升华。这其实是最朴素的虚实结合的道理。对学架构来说尤其如此。架构思维的感悟并不能一步到位，永远有进步的空间，需要我们在不断实践中感悟，升华自己的认知。
架构课内容的前四章为 “基础平台”、“桌面开发”、“服务端开发”、“服务治理”。
从内容上来说，由 “基础平台（硬件架构 / 编程语言 / 操作系统）”，到 “业务开发（桌面开发 / 服务端开发）”，再到 “业务治理（服务治理 / 技术支持 / 用户增长）”，基本上覆盖了信息技术主体骨架的各个方面。
有了骨架，就有了全貌，有了全局的视角。
前面四章，我们内容体系的侧重点放在了架构演变的过程。我们研究什么东西在迭代。这样，我们就不是去学习一个 “静态的”、“不变的” 信息技术的骨架，更重要的是我们也在学信息技术的发展历史。
有了基础平台，有了前端与后端，有了过去与未来，我们就有了真真正正的全貌。
我们博览群书，为的就是不拘于一隅，串联我们自身的知识体系，形成我们的认知框架。
这很难。
很多人都有关于 “广度” 与 “深度” 的辩证与困惑。全局观这件事情，对于心性上的修炼，比的是好奇心与韧性。
保持对这个世界的好奇心。看到新科技与新思想，先认同它，去体会它，理解它产生的需求背景与技术脉络，以此融入自己的知识体系。
持续地学习。
架构师需要有学习韧性。但并不是所有的技术都值得深耕。我们也都没有这个精力去这么做。我们要做到的是，随时想深入耕耘就能深入。
怎么深耕，更多的是结合自己的工作内容和兴趣。很多工程师会有困惑，觉得自己的工作内容平淡无奇，没法让自己进步，但实际上瓶颈不在于工作内容，在于自己心性的修炼。
好的架构师，拥有化腐朽为神奇的能力。
迭代能力的修炼：学会否定自己
架构师第三大能力的修炼，是迭代，是反思，是自我批判。
不管你喜不喜欢，工程师天天都在接任务，码代码。但是差别在于，你究竟在用什么样的态度来接任务，码代码。
关于码代码，不少优秀的工程师都有这样的体会：洋洋洒洒写了好多代码，过了半年一年，自己看着怎么看怎么不爽。
如果你有同感，那么恭喜你：你进步了。
但，接下来的事情更重要。
你是捏着鼻子忍着，继续接老板安排下来的新任务；还是，百忙里抽出一点时间，把之前写的代码改到你满意的样子。
这个改代码的过程，它之所以重要，是因为它才是真真正正的架构能力升华的过程。
通过迭代而升华。这是架构能力提升之路。你的收益不会只是你重构的那一个模块本身。通过重构，你建立了新的知识体系。它是内在根本性的变化，看不见但你自己可以体会得到。
接任务的态度也很重要。
面对每一个新的开发任务，都是一次重新审视架构合理性的机会。
就算这个模块从来没有交给过他人，所有代码都是你自己写的，也不代表这个模块就不会老化，发出臭味。这里面的原因在于，很多时候你给模块加上新功能的时候，往往会出现很多当初架构没有考虑到的场景，导致不得不用打补丁的方式把需求给满足了。
一个需求捏着鼻子做，两个需求捏着鼻子做，慢慢的系统就不堪重负，变得很脆弱，到后面加功能就会变得越来越困难。
所以，发现架构无法很方便地支持某个需求，就意味着架构存在缺陷，这时要及时停下来思考以下问题：
还有哪些潜在的需求，现在还没有收到，但是未来可能会需要去满足？
如果这些需求当初就提出来了，架构做成什么样更合理一些？
当前的架构设计，迭代到新架构设计，它的成本是什么样的？
在架构调整这件事情上，早迭代，小步迭代，比做一个大的重构版本要好。
结语
架构师成长之旅，是心性修炼之旅。我们需要记得，并不是理解了架构思维的原则，就能够做好架构。
架构之道，是虚实结合之道。理论与实践相结合。
从实悟虚，从虚就实，运用得当方得升华。架构思维的感悟并不能一步到位，永远有进步的空间，需要我们在不断实践中感悟，升华自己的认知。
从技能来说，我们可能把架构师能力去归结为：
理需求的能力；
读代码的能力；
抽象系统的能力。
但是架构师修炼之道，更难的是在心性上，这包括：
同理心的修炼，认同他人的能力。
全局观的修炼，保持好奇心和学习的韧性。
迭代能力的修炼，学会反思，学会在自我否定中不断成长。
如果你对今天的内容有什么思考与解读，欢迎给我留言，我们一起讨论。下一讲我们聊聊 “如何判断架构设计的优劣”。
如果你觉得有所收获，也欢迎把文章分享给你的朋友。感谢你的收听，我们下期再见。
分享给需要的人，Ta购买本课程，你将得20元
生成海报并分享赞 41
提建议
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
56 | 服务治理篇：回顾与总结
下一篇
58 | 如何判断架构设计的优劣？
精选留言(36)
小喵喵2019-11-18你是捏着鼻子忍着，继续接老板安排下来的新任务；还是，百忙里抽出一点时间，把之前写的代码改到你满意的样子。 已经是线上的代码，一旦发现之前的代码或者别的同事写的代码可以有改进空间，这样去改，一旦改出事故，后果很严重哦，我以前待的一家公司就是这样，领导要的是稳定，代码不允许随便改，没有出问题还好，要是该处了什么事故。这个季度的KPI就是C了或者更低了。老师怎么看待这个问题？？展开作者回复: 对我来说，C不重要，内心满足更重要
共 13 条评论50
Aaron Cheung2019-11-15认同他人 否定自己 的确是需要学习的 见过太多自己的项目天下无敌 别人的项目都是垃圾的工程师😂15
亢（知行合一的路上）2020-04-24改代码的过程，才是真真正正的架构能力升华的过程。这句话，震到我了！ 有时，自己写的代码，满足的需求，就放那里了，不会主动去看，后来增加新功能，直接改，时间紧迫，顾不了那么多了。虽有不合理的地方，也懒得改了，如果改，又得重新测试、发布，还可能出别的错误，就更畏首畏尾，代码质量不断下降，浪费了多少架构能力提升的机会啊！ 从现在开始，小步迭代，遇到不合理的地方，绝对不放过！不要说没时间，总能挤出来的！不要说怕出错，增加测试用例啊！不要找一切理由，都是借口！ 自己要成长，就要加速迭代！展开作者回复: 给你点个赞
14
spark2019-11-15有一种粮食叫精神食粮，这个专栏就是权且叫做架构精神食粮，吃了然后消化了，可以长生不老。 快乐啊，上帝创造了世界共 1 条评论9
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="30" height="30"><rect fill-opacity="0"/></svg>)
neohope2021-10-29好的架构师： 1、技术面足够宽，技术栈足够深，保持对新技术的敏锐性 2、理解行业，熟悉业务流程、业务和架构、业务和数据流 3、有足够的落地经验，达到公司项目规模的需要 4、可以正确理解需求，进行整体架构，并将架构落地的能力 5、对项目团队有足够的技术领导力，可以推动技术落地 6、了解团队主要成员能力特点，可以正确评估团队能力 7、了解项目具体情况，采用恰当技术栈，对项目走向有正确预判 8、和产品、研发、运维、测试团队，维持和谐的关系 9、有洁癖，但可以正确评估洁癖和其他任务的轻重缓急 10、布道精神，带领技术团队不断进步展开作者回复: 👍
8
名2019-11-15很有禅性，修为很高 用思想的理性视角，逻辑规则化了职业范畴上的人性5
丁丁历险记2019-11-15笔记 1 同理心修炼。接受他人的代码。重构，不为体验，消除臭味。 重构，容易出问题，难在同理心。 2 全貌 虚实结合之道，优先实。 好奇心，与韧性。 随时想深，就能深。好的架构师 有化腐朽为神奇之力。 3 迭代能力修炼。早迭代，小步迭代。 无法支持某个需求，架构不合适上。展开2![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="72" height="72"><rect fill-opacity="0"/></svg>)
程序员Artist2021-12-31两个点戳到我了。 1、“心一横做重构”，哈哈哈，内心决策描述的极其到位。 2、“洋洋洒洒写了很多代码，半年后阅读自己写的，怎么看怎么不爽。说明你进步了” 完了完了，我肯定是退步或原地打转了，我是怎么看怎么爽，有时候还会不自觉的内心惊叹：“小伙子可以的，当初咋想的，代码写的这么好”展开1
李二木2021-02-18架构师心性修炼 1 同理心 认同他人的能力 2 全局观 保持好奇心与韧性 3 迭代能力 迭代、反思、自我批判展开1- Geek0072019-12-24大道至简，不仅仅架构，许老师这张所谈到的内功做其他的角色也同样适用。谢谢1
leslie2019-11-15老师的"从实悟虚，从虚就实"个人非常认同：虽然架构师没做过，自己一路从开发->DBA->DBA&&OPS;各种架构见过不少，其实是"从现在看未来,从未来做现在"。 越来越觉得架构之路：就如同下棋，知道每个棋子的棋力以及什么时候能发挥什么样的作用，然后预估大致的情况，下出当下的棋招。1
Geek_7ae5722022-05-11我感觉我的设计能力升华的时候就是重构了一个一看就让人想离职的代码。而且收益明显：能更快速定位问题，快速支撑新的业务功能，更优雅的并行抓取下游数据
Geek_122dd92022-04-11确实过一段时间看自己的代码，怎么看怎么不顺眼- 程序员Artist2021-12-31很多人会说别人留下来的代码写的一塌糊涂，甚至是代码屎山。但其实这个在绝大多数情况是，是业务代码迭代发展的必然，想要避免很难很难。需要一波接一波的工程师架构师都有心一横的决心。 换个角度，我认为“正确看待”代码屎山，平常心看待这个问题是一种很大的进步。
南北2021-09-06理解他人，理解用户，反思自己
木木2021-08-26理解需求，读代码，系统抽象
林铭铭2021-07-14虚实结合，提高心性！
言十年2021-07-08能不动则不动跟公司文化还是有些关系
之渊2021-05-26第一次听到架构师要有同理心！还以为只是管理需要！666
xtepCool2021-04-22同理心在处理共同做一件事情的时候综合各方岗位职能和需求的粘合剂，站在他们的角度，综合他们的情况，再结合实际资源，做出比较好的决策或者资源调度。
