如何成为架构师？7 个关键的思考、习惯和经验

本篇文章5129字，读完约13分钟

编者按:微博平台和大数据技术专家秦迪加入微博已有13年。他负责微博平台通信系统的设计与开发，微博平台基本工具的开发与维护，微博平台的结构改进。他擅长解决复杂系统中的各种疑难杂症。原文来自微信公众账户聊天架构(id: archtime)，36 Kr授权转载。

工作了很长时间后，我发现了一个有趣的现象。从程序员和高级程序员到建筑师和专家，随着技术和能力的提高，有越来越多的事情我无法理解。这些问题有些来自与朋友的交流，有些是我自己的问题和答案，有些还不清楚。这篇文章将写这些问题。

如何更有效地学习？

许多新程序员起初找不到学习的方向，但我认为这些问题中的大多数会变得不那么明显，他们的工作方向会在一段时间后逐渐变得清晰。

但不久之后，每天可以学到的信息开始超过学习的能力，比如买未读的书、收集未读的帖子、积累马克之后从未关注过的文章，更不用说每天在微博上面对各种技术分享或新事物。

大多数人每天为自己学习的时间有限，因此如何提高现阶段的学习效率成为了需要解决的焦点。

谈论我自己在提高学习效率方面的经验其实很简单:系统学习。

我过去喜欢阅读看起来容易理解的博客或文章。每天，当我在微博微信上刷技术文章的时候，我可以把它们记下来，基本上几分钟就能写完。但是过了一段时间，虽然我读了很多东西，我还是有一种原地打转的状态，而且我没有感觉到任何实际的改善。

最后，我忍不住用一本厚书使劲咀嚼。突然，我觉得豁然开朗:我在阅读的时候学到了一个完整的知识网络，每个知识点都是相关的，与其他内容不同。与独立文章相比，这种全方位的理解更高。

读了这本书一段时间后，原本不在一个系统中的知识将逐渐被联系起来。例如，后端服务的开发，简单地梳理一下，就会变成这样:

在重复了几次痛苦的学习-梳理过程后，阅读一些独立的文章或材料往往会事半功倍，因为相应的知识可以在系统中找到，甚至有时一本书的一页只需要读一句话，如果你接触到足够的纸，你就可以掌握新的知识。

你怎么知道这些的？

工作中总是有各种各样的问题。几次，问题处理过程被总结并发送出去。之后，像滚雪球一样，越来越多的朋友来咨询问题，比如:

不久前，我帮助解决了一个性能问题。当系统压力稍高时，它将经常充满气相色谱，然后在压力降低后恢复。

在访问代码质量检查系统后，一个小伙伴发现，每次构建代码质量检查系统时，它都会报告一个无法解释的错误，并且无法键入包。

一些代码中有一个错误，我的朋友过来问我git如何回滚代码。

每当我问这个问题时，一些刚毕业的朋友会带着崇拜的目光看着我，然后大多数人会问:“你怎么知道的？”

事实上，虽然我一直在不断地学习，在工作中面临着无穷无尽的新问题，但大多数问题仍然会触及到我还没有掌握的领域。每当有人问我一些我不知道的事情，我都很开心:有什么比用问题学习更有效的学习方式呢？

幸运的是，在建立自己的知识体系的基础上，一个人通常可以很快地学习新知识，只需要多知道一个知识点就可以解决问题。

例如，频繁的完全垃圾收集的问题，以前已经检查过很多次了，主要是java程序或者jvm的内存泄漏，但是这次没有内存泄漏，垃圾收集的吞吐量是正常的，所以我只需要检查如何查看一段时间内创建的大部分对象的方法。

回到刚才的问题，我的朋友问我:“你是怎么学到这些知识的？”

答案是:在你问我问题后，我现在明白了。

架构师应该编写代码吗？

似乎偶尔你会看到一些关于架构师是否应该写代码的文章。我属于代码编写学校，因为我喜欢写代码。然而，当工作职责改变时，如何在编写代码和其他任务之间保持平衡就成了一个问题。

从个人效率的角度来看，我自己编写代码，这与很多人相比没有绝对的优势，甚至有些人编写代码的速度比我快。

然而，作为一名架构师，编写代码仍然会有一些好处。

一般来说，合格的程序员能很好地完成明确分配的任务。然而，在大多数情况下，“架构”这个词意味着架构师不涉及太多的细节，并且在架构图和代码实现之间仍然有一些距离。你不能保证每个人都会正确理解你的设计，或者当程序员在编写代码时遇到障碍时，他们会立即想出优雅的解决方案。

我以前写过一篇关于坏代码的文章。大多数糟糕的代码不是架构师的设计问题。如果程序员对设计没有很好的理解或者缺乏经验，他们经常会做出一些不可思议的事情。例如，我看到新毕业的程序员复制耦合的代码以防止模块耦合，或者试图将所有的逻辑写在一个函数中以“优化性能”。

如果这些问题不能被及时发现和纠正，那么这些地方就会变成“纠正错误代码”，或者“我没有写的代码”，或者“我已经看到那个代码”等等。这种问题是建筑师的责任吗？作为一个重视自己声誉的建筑师，我想是的。

在我看来，编写代码的架构师更像是做后勤支持的工作:在第一时间发现代码中可能存在的问题，警告其他人，或者给其他人提出改进建议，或者在必要时向其他人展示正确的姿态。

在大多数情况下，作为一名架构师，我不需要接管“核心模块”的开发。毕竟我能分配的时间太分散了，效率很难保证。很多人在专注的时候做得比我好得多。我只需要记住全局，需要适度的参与。

一般来说，架构师和程序员在某些方面有点类似于产品经理和用户之间的关系。大多数程序员不会告诉你他们想要什么，在哪里需要优化，甚至不知道。制造好产品的捷径之一是对用户做同样的事情。

练习:会议是一项技术性工作吗？

我想没人喜欢开会。作为一名程序员，很少有人想成为工作场所的社交蝴蝶。

然而，会议邀请只是一个接一个地出现:开发需求应该与产品相适应，项目计划应该与技术相适应，新成员应该召开评审会议，其他公司的几个大公司正在召开分享会议，出现问题时应该召开总结会议，每周会议应该由小组和部门召开，大项目每周开两次会议并不算过分。当一个小项目开始的时候开一个会不是太多了吗？调试时，我发现了一个坑。让我们快点讨论它。

有时我参加的会议在整个会议后与我无关，我徘徊了两个小时。最后，有人突然敲桌子说，“有什么问题吗？”好了，它不见了！"

也有可能有一次会议没有给你打电话。两个星期后，我突然收到一封电子邮件，催促开发进度。“当时，你没有参加会议。每个人都说你应该做这件事...你没看会议记录吗？”

我已经讲了很多，但我仍然认为会议是一项技术性的工作，尤其是对建筑师来说。

大多数技术人员会议不是新闻中的那种工作报告或长老会议。他们真的需要通过会议讨论一个具体的计划或者解决具体的问题。遗憾的是，我参加了很多会议，大部分会议都是在无谓的交流中浪费时间:几个人坐在同一个房间里，说着对方听不懂的话，最后得出的结论是:“会后我们再刷一遍。”

这在会议中不是问题。在程序员的日常交流中，很多人不知道如何交流。例如，偶尔，他们会收到一些非常严肃的电子邮件。打开后，屏幕上出现了许多单词，但他们从第一句话开始就不知道他在说什么，也没有动力去看看他们背后的东西。

大多数时候，沟通的核心不是你说什么，而是你想让别人知道什么，他做什么。良好的沟通可以显著提高工作效率，但许多人忽视了这一点。

恰当地沟通并不容易，但有几个简单的原则:

确保所有各方对背景有相同的理解，例如，在会议前简单地通过电子邮件交流，花30秒钟给会议的新参与者一个概要，或者让对方在讨论中解释他的理解。

去掉对方不能/不需要理解的内容，例如，告诉产品“cpu性能瓶颈是由该高并发队列中的锁实现问题造成的”，改为“我们发现了性能问题，持续了10分钟，10万用户收不到操作发送的不良广告，5分钟左右即可解决扩展问题。”

确保在对方失去注意力之前尽快说出要点，如故障排除问题的总结邮件。如果第一段是这样的:“在框架内使用xxx技术，并且这种技术的架构是这样的:blabla”，那么对方可能不知道你在说什么。可以替换为:“我在某个框架中发现了一个bug，需要尽快升级，否则xxx中可能会出现yyy问题。”具体的故障排除过程如下。

不要浪费别人的时间，说一些没有意义的内容，比如“这个需求不能实现”或者“这里不能有bug”。没人想听这些废话。

为什么别人的系统总是很糟糕？

许多程序员有很强的解决问题的能力，说如果他们想解决一个问题，他们可以在下午写数百行代码来实现这个功能。然而，有一种被忽视的感觉。我花了很长时间想用一个词来形容“这个东西”，最后想出了一个几乎无法表达的词:程序的生命力。

大多数程序都可以实现功能，但是如果你把“时间”作为一个维度，你会意识到一个合格的项目需要考虑更多的事情:更一般的用法、易于理解的文档、简单且易于扩展的设计等等。破坏程序的活力很简单:使它更加复杂和定制化，让更少的人参与进来。

我告诉过许多程序员程序的生命力，例如，让我编写的工具以类似于其他linux命令的方式运行，或者使用一些更容易理解但性能不佳的设计方法，或者请他参考当前业界的主流实践。许多人认为提这个要求没有什么意义。我认为这是一个例子。

许多公司应该有一些遗留系统，它们庞大、笨重、难以使用，而且几乎不可能维护。每个人都抱怨这些系统，并试图每天更换它们。然而，过了一段时间，我们会发现我们周围的新来者开始吐出当时取代遗留系统的系统。

“大多数系统在开始时运行良好，当时功能充足，可扩展性似乎还不错，但在开发人员离开后，这些系统都出现了问题。”

有更好的方法吗？

成为技术专家后的工作可以说是痛苦而快乐的。许多人会向你寻求建议。另一方面，太多人会向你寻求建议。

甚至有一段时间，我的日常工作是回答问题，从工具使用到困难的bug到架构设计，基本上从早到晚为各种小伙伴提供咨询服务。

我很快发现有些地方不对劲:有些问题太简单了，我想都不用想就能给出答案。为什么会有这样的问题？

后来，我在每次回答之前都问:

“你有更好的办法吗？”

少数人可以立即给出优化版本，甚至在我连续问了几次之后，他也可以给出几个优化版本；另一小群人会直截了当地说它不能被优化，就是这样。但是大多数人会犹豫地说出一些完全迷失方向的答案。

后来，我改为在每个答案前问两句:

“你想解决什么问题？”

“有更好的方法吗？”

效果好多了。许多小伙伴发现要解决的问题并不复杂，但实践出了问题。

然后我换成在每个答案前问三句话:

“他们想让你解决什么问题？”

“你有什么问题？”

“有更好的方法吗？”

现在第三句很少被问到。

成为建筑师最困难的门槛是什么？

在与一些程序员交流的过程中，很多人问我如何成为一名伟大的建筑师。

近年来我采访了很多人，发现了一个有趣的现象:很多自称是建筑师的人没完没了地谈论一个建筑，各种各样的技术术语像相声一样从他嘴里冒出来。三句话与高并发性和大数据是分不开的，但稍加询问后，你会发现许多基本概念缺失了。例如，声称精通高并发的人不能说出他所谓的高并发系统的瓶颈在哪里，声称精通架构设计的人不能理解他的系统如何保证高并发。

虽然建筑师听起来很高，但他本质上仍是一名工程师，不是科学家，也不是江湖骗子。不管你学了多少，你都需要练习。架构设计更多的是抽象和平衡:将复杂的需求抽象成简单的模型，并从功能、性能、可用性、研发成本等方面规划如何构建系统。这些内容需要更多的练习。

很多人不在像微博平台这样每天都需要接触建筑设计的地方工作，很多公司没有建筑工作给他们培训，所以他们努力在理论上工作。这些人的特点非常明显:他们开始做建筑设计时没有足够的信息，甚至不知道实际的场景。这种所谓的建筑往往是肤浅的，经不起推敲。

每年招聘后，我们都会为新人做一些建筑方面的培训。课程材料基本上包括与高可用性架构相关的主要方面，但是在学习了这些材料之后，我们能成为一名独立的建筑师吗？没有。相反，这只是一个开始，在新来者实际上已经完成了几个系统的几万个并发量之后，它将被认为是一个正式的进入:他们将知道当面对压力时如何权衡，并且他们只会在走过弯路之后找到捷径。

因此，我认为建筑师工作(以及其他许多工作)最重要的部分是实践。自夸很容易。与其拖着一些技术术语，不如真正做你正在做的系统。

丹尼尔和我之间有多远？

像很多人一样，当我毕业的时候，我觉得作为一名程序员，如果我努力工作，加上一点天赋，我可以取得一些成绩。

工作一段时间后，我越来越意识到自己和他人之间的差距，逐渐发现程序员之间的差距可能比人和猴子之间的差距更大。接受这个事实让我压抑了很长时间。

过了一会儿，我发现自己能够客观地评价自己的能力，并意识到距离并不那么重要，只要我努力跑得更快，就足够了。

这篇文章由读者提交，并不代表36英寸的立场。如果转载，请注明出处

“读完这篇文章还不够吗？如果你也开始创业，希望你的项目被报道，请点击这里告诉我们！”