《程序员必读之软件架构》作者Simon Brown：架构师与程序员的区别

摘要：全球知名软件架构独立咨询师、讲师Simon Brown在接受图灵社区专访时，表示开发者和架构师之间最大的区别就是技术领导力。退后一步反观大局是架构师必掌握的核心技能，开发者需经过经验积累才能成长为合格的架构师。

 

 

【编者按】Simon Brown是全球知名软件架构独立咨询师、讲师，创办了专门讨论软件架构问题的网站“编码架构” （CodingTheArchitecture.com）。他自称是写代码的软件架构师和明白架构的软件开发者。自2008年以来的7年时间 里，Simon在全球28个国家做过有关软件架构、技术领导力及其与敏捷的平衡等主题的百余场演讲，并于2012年8月在中国举办的ArchSummit 全球架构师峰会上以“郁闷的架构师”和“如何设计安全的架构”为主题发表演讲，深受与会者好评。Simon已为全球20多个国家的软件团队提供咨询和培 训，他的客户既有小型技术初创企业，也不乏全球家喻户晓的品牌公司。Simon著有《程序员必读之软件架构》一书，他在这本书中打破传统的认知，模糊软件 开发和架构在流程中的界限，进而为软件架构正名。近日图灵社区围绕程序员与架构师的区别对Simon Brown进行了访谈，下面为访谈内容。

---

问：开发者和架构师之间最大的区别是什么？

Simon Brown：架 构师和开发者一样，也经常写代码，简单的说，开发者和架构师之间最大的区别就是技术领导力。软件架构师的角色需要理解最重要的架构驱动力是什么，他提供的 设计需要考虑这些因素。架构师还要控制技术风险，在需要的时候积极演化架构，并且负责技术质量保证。从根本上讲，架构师是一个技术领导者的角色，这就是最 大的区别。

问：一位开发者如何才能成为一位架构师？他/她需要掌握哪些领域之外的能力？

Simon Brown：两 个字：经验。我认识的大部分优秀软件架构师同时也是出色的软件开发者，他们都是经过时间逐渐发展成为架构师的。你需要有退后一步看代码的能力，从而理解特 定软件系统背后的设计决策。退后一步才能看到“大局”，这是架构师必须掌握的核心技能。这就是为什么《程序员必读之软件架构》一书中加入了有关C4模型的 内容，这是一种从多个不同抽象层面理解软件系统的方法。这个方法有助于你退后一步反观大局。

问：你对软件架构的理解是否因为你的经历和实践而改变过？

Simon Brown：是 的。我对软件架构的理解是根据我在咨询公司工作时在各个项目中负责软件架构的经验形成的。咨询是一件好事，尤其从最近我开始从事独立咨询师这个工作之后， 我可以看到很多不同的团队，不同的架构，不同的技术，以及人们不同的工作方式。世界各地的文化多样性又为工作的复杂度增加了一个维度。无论是寻找特定问题 解决方案的过程，还是为各种想法去芜存菁的过程，这些经验和与我共事的人的反馈一起最终形成了我今天对软件架构的认识，这些思维也反应在了我的书中。

问：你书中的每一章内容都很有趣而且很精炼，有没有想过写几本详细论述《程序员必读之软件架构》中重要话题的书？

Simon Brown：我 写作这本书的目的是要创造一本让读者可以从头读到尾的书，但是你也可以通过粗略浏览来找到具体问题的答案。对于这个问题来说，没错，有一些相关主题没有出 现在这本书中，这些主题可以构成一本与《程序员必读之软件架构》相互补的书。比如，图表和建模的材料就可以扩充成一本完整的书，另外我和一个朋友也讨论过 要写一本关于架构模式的技术性更强的书。

问：你在书中也谈到了敏捷方法，你是如何看待现在流行的"敏捷已死"的说法的？

Simon Brown：我 听过很多人说“敏捷已死”，他们观点似乎来自两个主要视角。首先，敏捷这个品牌现在虽然已经成为主流，但是其背后的一些意义却在近些年消失殆尽。遵循敏捷 实践的软件团队有很多（比如每日站立会议，测试驱动开发等等）但是他们却并不知道为什么要遵照这些规则。盲目仿效敏捷实践并不是敏捷的核心精神。

还有一些团队，他们尝试了敏捷，但是结果却一团糟。我从软件架构的视角特别能注意到这件事。大部分敏捷方法并不明确讨论预先设计，而很多人把这点误解为在敏捷项目中不需要做预先设计。当然，这不是事实，而现在人们开始寻找所谓的传统开发和敏捷开发之间的平衡点。

敏捷并没有死。采用敏捷方式意味着不断地反思和调整你使用的方法，从而达到解决问题、变得更有效率或者更频繁地交付优秀软件的目的。团队要如何完成这件事完全是由他们自己决定的。

问：作为技术领导者，如何协调一个大型项目中不同架构师的协同工作？

Simon Brown：这 是一个复杂的问题，根据背景的不同，答案也有很多。在我的经验里，大多数大型项目都包含有一些小团队，可能是根据技术类型、子系统或组件区分的。在这种情 况下，每个团队一般都会有自己的软件架构师，因为必须有人要为这些零散的部分负责。为了要管理整个项目，协调合作，有以下几种方式：

一个单独的架构师来管理整个项目，然后通过和基于团队的架构师的合作来确保工作顺利进行。

基于团队的架构师共同协作，分享和执行架构领导者的角色。

某一位基于团队的架构师额外花费一些时间来管理整个团队。

第 一种方式是我最不喜欢的，因为多出来的这个人可能不会像其他基于团队的架构师那样投身到每天的工作中，而且他有可能缺少必要的背景信息，无法做出明智的决 定。在第二种和第三种方式之间选择的时候，我们可以根据基于团队的架构师的领导力和兴趣来决定。比如，强制一个不感兴趣的人来管理整个项目可能不会成功。 我个人比较倾向于第三种方式，但前提是其他基于项目的架构师也应该以某种程度参与进来，因为对整个项目的理解是必不可少的。

问：复杂是软件架构的敌人，很多人欣赏那些已经用了十几年的架构，但是这种情况下多场景预判会使得程序变得复杂。你是如何规划架构时间点上的规模和设计的呢？

Simon Brown：简 单的答案就是一开始就使用简洁的设计，然后明确地思考模块化。软件系统随着时间很容易就会发展成“大泥球”，对于需求不断变化的软件系统来说，维护性和适 应性的最大影响因素就是不同事物间的耦合程度。如果你从一开始就考虑了模块化，把软件系统分解成高内聚低耦合的小模块单元，在未来你就可以更轻易地对系统 做出改变。更进一步说，这意味着你定义的软件架构应该反映在代码中。正如我在书中所说，事实并不永远如此。我去年在一次大会中的演讲（抱歉，演讲是英文的 而且在YouTube上）中深度讲解了这个话题->https://www.youtube.com/watch?v=ehH3UGdSwPo

问：你认为从10万用户扩展到1亿用户的架构存在吗？如果存在的话，这些架构具有超强扩展性的原因是什么？

Simon Brown：我 确定这样的架构确实存在，但是在构造这些架构之初时，架构师可能并没有设想到如此强的扩展能力。每个互联网级别的大型网站背后的故事都很有趣，它们大多数 都已经经历过在开发、部署、运维的同时持续发展架构的阶段。做出架构决策的关键就在于理解利弊和确定优先级。你可以在CAP定理中看到类似的情况。一旦你 明白了不能拥有一切，就会更容易做出架构决策了。

问：什么样的架构能够做到快速响应频繁变化的需求？

Simon Brown：和之前的答案一样，简洁的设计和模块化会让你可以快速响应快速变化的需求。如果你需要经常改变架构，但只想改变其中的一部分，为了防止为每个小变化重新部署整个系统，采用微服务架构是一个明智的选择。

问：有没有什么事是架构师永远都不应该做的？

Simon Brown：有，软件架构师永远都不应该停止编程和停止学习！