Simon著有《程序员必读之软件架构》一书，深受与会

Simon Brown 是世界知名的软件架构独立顾问和讲师。他创立了网站“代码架构”（），专门讨论软件架构问题。他称自己为编写代码的软件架构师和了解架构的软件开发人员。自 2008 年以来的 7 年里架构师，Simon 在全球 28 个国家就软件架构、技术领导力及其与敏捷的平衡等主题发表了 100 多场演讲，并于 2012 年 8 月在中国举行的全球大会上发表了演讲。建筑师峰会以“沮丧的建筑师”和“如何设计一个安全的架构”为主题发表演讲，受到与会人员的一致好评。Simon 为全球 20 多个国家/地区的软件团队提供咨询和培训，他的客户范围从小型科技初创公司到全球家喻户晓的名字。Simon 是《程序员必读的软件架构》一书的作者。在这本书中，他打破了传统的认知，在过程中模糊了软件开发与架构的界限，进而为软件架构的名称辩护。

问：开发人员和架构师最大的区别是什么？

架构师和开发人员一样，经常编写代码。简单来说，开发人员和架构师最大的区别就是技术领导力。软件架构师的角色需要了解最重要的架构驱动程序是什么，他提供的设计需要考虑这些。架构师还控制技术风险，在需要时积极改进架构，并负责技术质量保证。从根本上说，架构师是技术领导者，这是最大的不同。

问：开发人员如何成为架构师？他/她需要掌握哪些能力领域？

两个字：经验。我认识的大多数伟大的软件架构师也是伟大的软件开发人员，他们随着时间的推移发展成为架构师。您需要能够退后一步查看代码以了解特定软件系统背后的设计决策。退一步看“大局”是建筑师必须掌握的核心技能。这就是为什么《程序员必读的软件架构》这本书包含有关 C4 模型的内容，这是一种在许多不同抽象级别上理解软件系统的方法。这种方法可以帮助您退后一步，看看更大的图景。

Q：你对软件架构的理解是否因为你的经验和实践而改变了？

是的。我对软件架构的理解源于我在咨询公司工作期间从事各种项目的软件架构工作的经验。咨询是一件好事，尤其是自从我最近开始担任独立顾问以来，我可以看到很多不同的团队、不同的架构、不同的技术以及人们不同的工作方式。世界各地的文化多样性为作品的复杂性增加了另一个维度。无论是寻找具体问题的解决方案的过程，还是收集点点滴滴的想法的过程，这些经历，以及与我共事的人的反馈，最终塑造了我今天对软件架构的理解，这些想法都体现出来了在我的书中。

问：你书中的每一章都很有趣且简洁。你有没有想过写几本书详细介绍程序员软件架构中的重要主题？

我写这本书的目标是创造一本读者可以从头到尾阅读的书，但你也可以通过略读找到特定问题的答案。就此而言，是的，本书未涵盖一些相关主题，这些主题将构成程序员软件架构的补充书。例如，图表和建模材料可以扩展成一整本书，我和一个朋友讨论了写一本关于架构模式的技术性更强的书。

问：您还在书中谈到了敏捷方法。您如何看待现在流行的“敏捷已死”的说法？

我听过很多人说“敏捷已死”，他们的观点似乎来自两个主要方面。首先，虽然敏捷品牌现在已经成为主流，但它背后的一些含义在近几年已经消失了。有许多软件团队遵循敏捷实践（每日站立会议、测试驱动开发等），但他们不知道为什么要遵循这些规则。盲目地模仿敏捷实践并不是敏捷的核心精神。

还有一些团队尝试过敏捷，但结果一团糟。从软件架构的角度来看，我特别意识到这一点。大多数敏捷方法都没有明确讨论前期设计，许多人误解这意味着敏捷项目不需要前期设计。当然，事实并非如此，现在人们正在寻找所谓的传统开发和敏捷开发之间的平衡点。

敏捷并没有死。采用敏捷方法意味着不断重新思考和调整您使用的方法，以解决问题、提高效率或更频繁地交付出色的软件。团队如何实现这一点完全取决于他们。

问：作为技术负责人，您如何协调不同架构师在一个大型项目中的协同工作？

这是一个复杂的问题，根据上下文有许多答案。根据我的经验，大多数大型项目都包含小型团队，可能会因技术类型、子系统或组件而有所不同。在这种情况下，每个团队通常都有自己的软件架构师，因为必须有人负责这些部分。为了管理整个项目，协调配合，有以下几种方式：

一个架构师管理整个项目，然后与基于团队的架构师合作以确保顺利进行。

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

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

第一种方式是我最不喜欢的，因为额外的人可能不像其他基于团队的架构师那样致力于日常工作，而且他可能缺乏必要的背景信息来做出明智的决定。在选择第二种和第三种方法时，我们可以根据基于团队的架构师的领导力和兴趣来决定。例如，强迫一个不感兴趣的人管理整个项目可能不会成功。我个人更喜欢第三种方法，但前提是其他基于项目的架构师也应该在某种程度上参与，因为对整个项目的理解是必不可少的。

问：复杂性是软件架构的敌人。很多人欣赏已经使用了十多年的架构，但是在这种情况下，多场景预测会使程序变得复杂。您当时是如何规划架构的规模和设计的？

简单的答案是从简洁的设计开始，然后明确地考虑模块化。随着时间的推移，一个软件系统很容易发展成一个“大泥球”。对于一个需求不断变化的软件系统，影响可维护性和适应性的最大因素是不同事物之间的耦合程度。如果从一开始就考虑模块化，将软件系统分解成高内聚、低耦合的小模块化单元，以后可以更轻松地对系统进行更改。更进一步，这意味着您定义的软件架构应该反映在代码中。正如我在书中所说，情况并非总是如此。我在去年的一次会议上的演讲中深入讨论了这个话题（对不起，演讲是英文及以上的）->

问：您认为有一种架构可以从 10 万用户扩展到 1 亿用户吗？这些架构具有超级可扩展性的原因是什么（如果有的话）？

我确信这样的架构确实存在，但是架构师在构建它们时可能没有设想到这样的可扩展性。每个大型 规模网站背后的故事都很有趣，它们中的大多数都经历了开发、部署、运营和继续发展其架构的阶段。做出架构决策的关键是了解优缺点并确定它们的优先级。您可以在 CAP 定理中看到类似的情况。一旦你明白你不可能拥有一切，就更容易做出架构决策。

Q：什么样的架构可以快速响应频繁变化的需求？

与之前的答案一样架构师，简洁的设计和模块化将使您能够快速响应快速变化的需求。如果你需要频繁地改变架构，但只想改变其中的一部分，为了防止每次小的改变都重新部署整个系统，采用微服务架构是一个明智的选择。

问：有什么建筑师不应该做的事吗？

是的，软件架构师永远不应该停止编程和学习！