Architecture 项目何时不需要应用程序架构师？

中型或大型项目是否不需要建筑师？我曾参与过许多项目，其中涉及的开发公司选择不指派应用程序架构师。要么软件是有机构建的，很少考虑设计，要么设计责任落在高级开发人员身上

---

没有架构师的动机从成本考虑到相信开发方法使体系结构角色变得不必要（这一论点可以针对敏捷开发）。一些开源项目是基于集体贡献的原则而不是基于建筑领导力的开发。

我不得不在这里用一个类比。不久前（相对而言），人们可以在没有建筑师或建筑设计图的情况下建造房屋。他们砍伐了一些木材，用学到的技能来切割和刨木板，并建造了自己的房子。教堂、城堡等等……当然，他们有建筑师和工程师。但绝大多数时间是人们利用传下来的技能建造房屋

这些房子完成了任务，但没有持续那么久。它们可能有点漏水，它们可能很难改善，等等，但是很容易用水来加固地基，然后添加木材。 现代房屋有基础设施可供插入，必须符合规范等。我们的房屋设计需要由建筑师创建或批准，然后才能建造。建筑师确保所有的东西都符合标准，并且房子能够直立并且适合居住

---

---

应用程序也不例外。我们并不是生活在一个复杂的结构不需要架构就可以摆脱的世界里。当然，我可以为我的库编写一个数据库作为一个简单的练习；我也可以为我的图书馆建造书架，而不需要建筑师的参与。但是，一旦你超越了简单的结构，你就应该绝对确保有人关注全局——无论你的结构（房子或应用程序）是否会做它需要做的事情，是否与其他人相处融洽，以及它是否符合在构建时设定的规则。

如果您已经有了一个允许您构建项目的架构/系统模式，那么您根本不需要架构师

我在大学教软件架构，我们认为架构师带来的核心技能是一个系统的、彻底的设计过程，它满足所有利益相关者的需求，并仔细考虑相互竞争的利益。架构师必须拥有大量的技术知识，但开发人员拥有相同的知识（甚至更多）并不少见

关键是捕捉质量场景并了解如何应用满足这些质量的设计技术/模式。或者，如果你必须的话，在飞行中发明一些东西

行业中的体系结构重用率很高，常常达到架构师多余的程度

因为我经常谈论这件事，我真的可以继续下去

更新： 我想我应该整理一下其他答案中表达的一些想法

• 建筑师是一个中心沟通点
• 架构师传达设计——优秀的架构师会有效地传达设计
• 建筑师为产品/项目带来基本经验
• 更大的建筑需要更大的设计、更多的规划、原型等，需要有人确保“正确的系统是正确的”
与开发者相比，架构师认为开发者是利益相关者，并执行策略来处理他们所期望的非运行时质量（可扩展性、可维护性、可测试性、可重用性、可配置性（度量））。

定义“需要”

毫无疑问，您可以在没有中心愿景或领导的情况下构建大型产品。它只会花费更长的时间，有更多的bug，更难维护，并且需要更多的工时来完成

根据我的经验，拥有一个应用程序架构师的好处远远多于缺点，而且项目越大，效果越大

现在，您可以做一些事情来减轻这种影响，例如，拥有关于应用程序预期设计的强大而完整的文档，开发人员会忠实地遵循这些文档——但这只是让文档取代应用程序架构师，这并不是一种真正不同的方法

敏捷开发可以取得成功，但它的成功在于拥有一个良好的开发团队机器，每个开发团队都同意程序设计的基本概念，并且当他们做出错误的决策并纠正彼此的错误时，他们都能很舒服地相互指出

同样，您并没有真正取代应用程序架构师的角色，您只是将职责分散到一群人身上

---

简单的事实是，这个角色[我]是你想要坐的东西。如何安排座位取决于你自己，但最行之有效的方法是让一个人来做

在我工作的地方，我们有一个大型项目的建筑师。如果你喜欢“理智的声音”，架构师是一个桥梁，在业务分析师风格的角色（“这是我们认为行业需要的”）和高级开发人员（“这就是它可以工作的方式”）之间架起一座桥梁。它们提供了软件应该如何开发的一致观点——如果您愿意，可以从更大的角度来看

开发人员四处走动，尤其是优秀的开发人员，在我看来，项目的一致性是关键。建筑师专注于项目的某个领域（记住，大型项目），不会四处走动，因此他们对将要实现的目标以及我们应该如何实现目标有着深刻的理解

它们还提供了一条“平滑曲线”，用于处理您在chan中遇到的触发器情况