应用程序架构师应该编写代码吗？

Posted 2023-02-22

【中文标题】应用程序架构师应该编写代码吗？

【英文标题】：Should application architects write code?

【发布时间】：2010-09-17 18:09:45

【问题描述】：

这是一个双方都有观点的常见问题。赞成的人会争辩：

要为编码人员设计一个系统，您必须了解如何编码（并且是编码） 您无法在不了解地面发生的情况的情况下设计系统 架构不仅仅是粗略的设计，而是在代码级别适应不断变化的需求

另一方面，

架构是高级角色，不应关注实现细节 编码是一种面向细节的、低调的功能，与架构的风险管理和宽广的视野性质不符 架构是关于技术风险管理而不是实施 架构关乎领导力。很难从背后领导

根据我的经验，架构师不应该花费大量时间进行编码，而必须主要通过主要开发人员的沟通、审查和站立来与代码库保持联系。如果您花费大量时间进行编码，您就会忽略高层次的问题，从而无法有效地管理技术风险。

【问题讨论】：

编码阻碍人们看到的“高级问题”是什么？

【参考方案1】：

即使您反对编码的论点是有效的，我认为开发团队尊重您和您的设计决策也很重要。如果您与他们一起“承受架构决策的后果”，那么他们不太可能质疑他们。

一直以来，我看到架构师与编码方面脱节，而他们的开发团队知道这一点。他们没有得到太多尊重。

【讨论】：

我同意尊重很重要，但作为一名有效的技术风险经理同样重要，尤其是从客户的角度来看。如果你在机舱里呆的时间太长，你就无法驾驶这艘船。

@Richard Dorman，很好的比喻！我明白你的意思，补充一点，我认为成为一名更好的建筑师就是平衡硬币的两面。你需要管理风险和委派，但你需要证明你为什么是架构师。这有点像马基雅维利主义。

我同意扎卡里的观点；当然，这是一种平衡。您只需证明 1) 您对自己的设计有足够的信心愿意自己编写代码；2) 您仍然对编程有足够的了解，不会创建脱离现实的设计

【参考方案2】：

Ab-so-frickin-lutely

没有什么比与现实脱节的建筑师更糟糕的了。

工作的一部分是让你的脚脚踏实地，让你的头在云端。

【参考方案3】：

只是为了给我两分钱（以及我对“建筑师”的看法）

我相信有几种类型的架构师，每一种都在自己的领域中：

业务和功能架构师：他们关心业务运营和功能工作流程，他们实际上不应该编码，因为他们必须能够将自己从任何类型的实现中抽象出来，并且他们必须制定功能规范，让技术解决方案保持开放。

应用架构师：他们将功能域（如“损益分析”）划分为应用程序（如“投资组合处理器”、“启动器”、“调度程序”、“gui” )。 他们不需要编码，但他们应该是以前的编码员，以便清楚地了解他们的架构必须解决的技术挑战。他们的主要技能不是编码，而是倾听技术同事的意见以选择正确的解决方案。然后，他们将产生必须实施（编码）的技术实施。

技术架构师：他们负责选择和/或实施技术框架（适用于任何功能项目的通用框架，如 KPI、日志记录、异常管理），并且他们 绝对应该编码（并且编码良好），因为它们的组件将被所有其他职能团队使用。

开发架构师（嘿，that's me ;)）：负责开发工具和流程以及技术调查，他们应该编码并热爱编码 也是如此。

所以我相信答案不只有一个：这取决于您的架构领域和专业知识：当谈到“应用程序架构师”时，我相信后三个类别可以有不同的编码经验......

【讨论】：

我通常对以下角色进行区分：业务分析师/系统分析师（无编码）、解决方案架构师（无编码）、基础架构架构师（无编码）、应用程序架构师（可能是代码）、首席开发人员（绝对代码）

有趣：我了解基础架构架构师（他们可能会编写代码，尤其是用于监控其架构的 php 网站！）而且我不熟悉“解决方案”架构师......你为什么不发布你的愿景在一个单独的问题？ ;)

fowler 将其分解为企业架构和应用程序架构

“开发架构师”对我来说听起来像是“团队负责人”。

不，完全不是：它是关于开发流程的架构师，而不是关于实际项目的开发，这需要功能和技术知识

【参考方案4】：

我认为建筑的角色正在发生变化。我看到越来越少的象牙塔架构师为低级程序员设计一个完整的系统以在瀑布过程中实现。

在进行迭代项目时，架构师和程序员之间的沟通变得更加重要。架构师是团队的一部分，应该能够与程序员一起处理不断变化的需求和新想法。在这种情况下，架构师和程序员的工作关系更密切。我见过开发主管担任架构师角色的团队，他们为非常复杂的解决方案提供经过深思熟虑的架构。

编辑回复评论 我认为在应用程序、解决方案和企业架构师之间的区别有点人为，在很多情况下并不真正适合。安全架构师、数据架构师等角色在职责之间提供了更清晰的区分。您可以在这里查看更多详细信息http://stevendwright.home.comcast.net/~stevendwright/ArchRoles.htm

顺便说一句，再次阅读您的问题后，我注意到许多反对编码架构师的论点似乎表明架构师具有强大的管理/领导角色。我认为将管理和架构角色分开是个好主意。让您的技术人员将他们的时间分配给编码和架构，而不是管理和架构。

【讨论】：

在这种情况下是否值得区分应用程序、解决方案和企业架构师？

@Richard Dorman，也许不值得对这个问题进行区分，但对于更广泛的问题“我能做些什么才能成为更有效的架构师？”进行区分绝对是有意义的。跨度>

【参考方案5】：

是的。多年未编写代码的软件架构师与构建产品的现实失去了联系。他们开始制作具有更高抽象级别的宏伟设计，这似乎一直在推迟他们的发货日期。

【参考方案6】：

我参与过的每个项目都包括一位架构师，他没有将大部分时间花在代码上，由于缺乏实践知识，因此遇到了问题。

这包括我担任建筑师的项目 :-)

现在是个人的大红旗。

我同意所有支持编码架构师的论点。反对的论点对我来说并不好。

代码需要抽象应用程序中的高级概念和低级概念。除非设计和代码在所有级别上集成，否则解决方案将不是最佳的。

至于“编码是一种面向细节的、低头的功能，这与风险管理、架构的宽广视角性质不一致”——根据我的经验，这是一种宽广的视角——尤其是风险管理——让编码人员变得更好而不是更差:-)

“架构是关于技术风险管理，而不是实施”——并非如此。这是关于风险管理和实施（以及一堆其他东西）。

“架构是关于领导力的。很难从后面领导”——为什么编码会让你落后？就我个人而言，我发现最好的领导方式是和你一起工作的人在一起。

【讨论】：

+1 - 你提出了一些好的观点。我确实认为有些业务或产品专家可以担任项目的领导者，但他们不会（也不能）编码。然而，世界上最好的人是有经验、智力灵活性和沟通技巧来完成所有级别的工作

【参考方案7】：

我（我认为我）是一名建筑师，编码是这份工作的乐趣所在。

然后您会看到您的想法正在变为现实，您可以看到您的设计正在运行，并且您可以看到设计中的错误（无论如何为时已晚，但下一次......）

【参考方案8】：

是的，以保持他们的编码经验。

【讨论】：

有一种观点认为架构与编码无关，几乎完全与风险管理有关。我至少见过一个项目，架构师根本没有接触过代码库。所有的设计都是在 UML 中完成的。该项目没有成功！

可能因为架构师缺乏编码经验而没有成功。我认为一个好的架构师也需要是一个好的程序员。

【参考方案9】：

有架构师，也有 IT 战略家。如果您正在领导一个涉及多个部门的 500 人的集成项目，那么不，它会妨碍您。如果您在一个开发项目中领导多达几十个人的设计和实施，那么可以。否则，您将不太可能对使用架构的日常现实有适当的洞察力。

【参考方案10】：

我认为他们不需要对应用程序中的所有内容进行编码。但是应该给他们一些任务。一些“架构师”基本上是没有技术经验的黑客，他们将自己伪装成“传奇编码员”和设计系统，如果你没有架构，你将不得不做的工作量增加数周或数月。如果他们不能编写代码，他们就没有这个角色的业务......因为这个想法是一个架构应该使应用程序更容易开发和维护。但是如果架构师不能开发，他或她怎么知道如何制作架构？

此外，即使是最好的架构师也会做出错误的决定。有时某些东西在白板上看起来很棒，但实际上架构决策最终使事情变得比应有的困难得多。如果架构师不得不吃他/她自己的狗粮（并使用架构），他们更倾向于想要纠正错误的决定或围绕它们设计方法。同样通过触摸代码，他们至少对它有点熟悉。因此，如果开发人员带着编码问题来找他们，架构师的眼睛不会呆滞，因为他/她解雇了开发人员并说开发人员做错了，但没有提供关于正确方法的见解。

架构师不需要在代码库中进行大型项目。但他们至少应该在代码库中做一些小任务，迫使他们使用自己的架构。此外，小任务可能会涉及阅读大量其他人的代码，以让他们了解人们如何使用该架构以及是否可以做任何事情来改进它。

【讨论】：

原型设计迫使建筑师吃狗粮。

只有那些决定进行原型设计的人......加上这种方式，他们可以看到架构的实际使用情况。要么教开发人员“正确”的方式，要么看到他/她的方式不现实。

【参考方案11】：

正如 Vlion 所说，在一个以开发人员为主的社区中提出这个问题意味着答案将倾向于“是”。

作为一个在职称中有“建筑师”但最近还获得了“杰出工程师”徽章的人，我的忠诚被撕裂了。总的来说，我认为编码通常不能有效地利用架构师的时间。那我该怎么办？

了解业务。 了解用于支持业务的系统。 与业务部门合作制定 IT 战略和策略。 确保当前项目是以长远的眼光完成的，项目经理专注于短期的眼光。

那么建筑师应该如何与现实保持联系呢？我认为通过定期会议和走访，只是与各个级别的人交谈并为沟通的***加油。

【参考方案12】：

我开始相信，“实现细节”通常不是细节（从某种意义上说，当您将某些特定的实现问题视为可以被视为“建筑”视角）

【参考方案13】：

应用程序架构师必须能够定义应用程序架构、设计应用程序、实施模式并指导其他人编写代码。如果你不能做这些事情，那么你就不是应用程序架构师。

【参考方案14】：

有时，他们必须编码。例如，当团队只有一个人时。

在我看来，他们可以根据需要编写代码，但不能丢失大局。每天都改变设计的结构是不行的。

【参考方案15】：

你是在一个编码网站上问这个的。你会让基本上每个人都支持“是”。

我的观点是，是的，但仅足以跟上不断变化的需求，仅此而已

【讨论】：

我不太明白你的第二句话，但至于你的第一句话；代码偏差并不意味着回答者是错误的。

【参考方案16】：

由于这里的每个人都是编码员，所以最喜欢的肯定是地狱-是的答案-我不会有任何不同意见。

但我认为finer grained answer 更正确，因为它适当地重视领域专业知识。对软件知之甚少但只是使用它的人是如此宝贵。

架构角色的划分方式似乎取决于组织的规模和性质。

如果我按照自己的方式去做，我会给客户一个故事架构师的角色，如果他们写出好的、有用的、详细的故事和用例。

【参考方案17】：

只编写接口算作代码吗？如果是这样，那么这是我对架构师的最低期望，而在其他情况下，他们可能会提供更多代码，例如带有方法存根的类。

【参考方案18】：

架构是软件开发人员的核心技能。对于架构师来说，不编码可能有一些罕见的情况，但我不记得在我自己的经验中遇到过这样的情况。

架构师必须在项目中编写代码，或者至少完全能够编写项目代码。第二部分意味着他们必须能够使用团队其他成员使用的工具和技术进行编码。 （不继续写代码，要保持这些技能肯定是非常困难的。）

最后，当架构师负责选择其他人使用的工具和技术时，如果不实际使用建议的工具，他们就无法很好地做出这样的选择。在这种情况下，非编码架构师迅速退化为一个尖头发的老板，办公桌上放着一堆小册子。

【参考方案19】：

我想知道为什么没有人提到可以替代编码的代码审查或结对编程。

与编写代码相比，我花更多的时间阅读代码并与同事一起解决问题。这让我对代码、其结构和复杂性的理解与自己编写几乎相同，而且耗时少得多。当我编码时，我这样做是为了好玩或探索新技术（这是我发现编码有用的唯一地方）。

【参考方案20】：

架构是一个高级角色，不应该关心实现>细节

代码就是设计。想象一下，一位建筑师设计了漂亮的建筑，但拒绝进入实施细节，例如在哪里放置紧急出口、管道、电力、电梯或建筑法律问题。

* Coding is a detailed oriented, heads-down funtion which is at odds

具有风险管理，视野开阔 建筑的本质

在编写代码时，首先要关注细节。然后你以更广泛的关注点进行重构。

架构是关于领导力的。后面很难带路

软件开发的前线是编码。可能是产品经理或者项目经理不会编码。但是建筑师需要这样做。也许他应该花更多的时间重构来展示代码有多好。这样，他以身作则。

【参考方案21】：

冒着偏离主题的风险……

在大型应用程序中，架构师可能无法及时了解正在编写的代码。此外，由于其他重要职责，他不可能编写代码。话虽如此，我还是建议架构师不要放弃正在开发的代码库的大局。这可以通过监控代码库的代码覆盖率、代码质量指标、静态代码分析等来实现。他应该使用上述标准定期评估代码质量。 “持续集成”的做法在这里可以提供帮助。

【参考方案22】：

这个标准的开发人员回答是架构师也应该编码。但它是一种将技术放在首位的开发者。但我倾向于不同意。是的，拥有一些编码技能是有益的，以便能够审查代码。

但架构师唯一要做的就是将业务需求与实施结合起来。在我们的例子中是代码。如果你有一个非常复杂的系统，你不能同时编码和做架构，因为你在太多不同的抽象级别上操作。

相反，您应该能够依赖开发人员。他们应该能够描述实现的各个方面，以及它如何适应您向他们指出的业务需求。选择什么技术是建筑师的决定，但要做出这个决定，他必须进行研究或利用过去的经验。这并不意味着他不与开发人员交谈，或者让他们研究特定技术以查看架构是否真的有效。