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

Question

这是一个经常被问到的问题，双方都有意见。赞成的人会争辩说：

• 要为编码器设计系统，您必须了解如何编码（并进行编码）
• 如果不了解地面发生的情况，就无法设计系统
• 架构不仅涉及广泛的笔画设计，还涉及适应代码级别不断变化的需求

另一方面，

• 架构是一个高级角色，不应该关注实现细节
• 编码是一种详细的，低调的功能，与风险管理，建筑的广阔视野不一致
• 架构是关于技术风险管理而非实施
• 建筑是关于领导力的。
很难从后面领导

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

Answer 1

即使您反编码的论点有效，我认为开发团队尊重您和您的设计决策也很重要。如果你的架构决策“及其后果”与它们一起“受到影响”，那么它们 就不太可能对它们提出质疑。

我一直看到那些与编码方面脱节的建筑师，他们的开发团队都知道它。他们没有得到太多尊重。

Answer 2

<强>的Ab-SO-frickin-lutely

没有什么比一个与现实失去联系的建筑师更糟糕了。

将脚放在地上，将头放在云端，这是工作的一部分。

Answer 3

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

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

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

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

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

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

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

Answer 4

我认为架构的作用正在发生变化。我看到越来越少的象牙塔建筑师为低级程序员在瀑布流程中设计整个系统。

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

编辑回复评论
我认为在应用程序，解决方案和企业架构师之间的区别有点人为，并且在许多情况下并不真正适合。安全架构师，数据架构师等角色可以更清楚地消除责任。您可以在此处查看详情http://stevendwright.home.comcast.net/~stevendwright/ArchRoles.htm

顺便说一句，从再次阅读你的问题后，我注意到许多反对编码架构师的论据似乎表明了建筑师的强大管理/领导角色。我认为将管理和架构角色分开是个好主意。最好让技术人员在编码和架构之间划分时间，而不是在管理和架构之间划分时间。

Answer 5

是。多年未编写代码的软件架构师失去了构建产品的现实。他们开始制作具有更高抽象水平的宏伟设计，这似乎会使他们的发货日期不断下滑。

Answer 6

我所参与的每个项目都包括一位没有花费大量时间的建筑师，因为缺乏实践知识而导致代码出现问题。

这包括我是那个建筑师的项目： - ）

现在是个人大红旗。

我同意支持编码的架构师的所有论据。反对的论点不适合我。

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

至于“编码是一种详细的导向，低调的功能，与风险管理，建筑的广阔视野不一致” - 根据我的经验，广泛的观点 - 特别是风险管理 - 使更好的编码员不会更糟:-)

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

“建筑是关于领导力的。很难从后面领导” - 为什么编码会让你落后？就个人而言，我发现最好的领导地点是与你一起工作的人。

Answer 7

我（我想）我是一名建筑师，编码是让这项工作变得有趣的原因。

然后你看到你的想法变得生动，你可以看到你的设计有效，你可以看到设计中的错误（无论如何都太晚了，但下次......）

Answer 8

是的，保持编码经验。

Answer 9

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

Answer 10

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

此外，即使是最优秀的建筑师也会做出糟糕的决定。有时在白板上看起来很棒，但实际上，架构决策最终会使事情变得比应有的更难。如果建筑师必须吃他/她自己的狗食（并使用建筑），他们更倾向于想要纠正错误的决定或围绕他们设计方法。通过触摸代码，他们至少有点熟悉它。因此，如果开发人员遇到编码问题，那么建筑师的眼睛就不会眩晕，因为他/她解雇了开发人员，并说开发人员做错了，但没有提供正确的方法。

架构师不需要在代码库中执行大项目。但他们至少应该在代码库中执行小任务，迫使他们使用自己的架构。此外，小任务可能涉及阅读许多其他人的代码，以使他们了解人们如何使用该架构，以及是否可以采取任何措施来改进它。

Answer 11

正如Vlion所说，在开发商占主导地位的社区中提出这个问题意味着答案将倾向于“是”。

作为一名拥有“建筑师”职称但最近也被授予“杰出工程师”徽章的人，我的忠诚被撕裂了。一般来说，我认为编码通常不能有效地利用建筑师的时间。那我该怎么办？

• 了解业务。
• 了解用于启用业务的系统。
• 与IT战略和战术合作。
• 确保当前项目以长期观点完成，项目经理专注于短期观点。

那么建筑师应该如何与现实保持联系？我认为通过定期会议和走路，只是与各个层面的人交谈，并为沟通的轮子上油。

Answer 12

我开始相信，“实施细节”往往不是细节（从某种意义上说，当你将一些特定的实施问题视为仅仅作为细节的细节时会出现许多问题“建筑“视角”

Answer 13

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

Answer 14

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

我的观点是，是的，但只足以满足不断变化的需求，不再需要

Answer 15

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

在我看来，如果他们想要，他们可以编码，但不能丢失大局。不可缺少的是每天改变设计的结构。

Answer 16

由于这里的每个人都是编码员，所以最喜欢的是地狱 - 是的答案 - 你不会对我产生任何分歧。

但我认为finer grained answer更正确，因为它恰当地重视了专业知识。知道小软件但只是使用它的人非常有价值。

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

如果我按照自己的方式行事，如果他们写好，有用，详细的故事和用例，我会给客户一个角色扮演者。

Answer 17

只是将接口编写为代码？如果是这样，那么这是我对架构师的最小期望，而在其他情况下，可能会有更多来自它们的代码，例如带有方法存根的类。

Answer 18

架构是软件开发人员的核心技能。可能有一些罕见的情况，建筑师不需要编码，但我记不起在我自己的经历中遇到过这样的场合。

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

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

Answer 19

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

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

Answer 20

  

架构是一个高级角色，不应该关注实现＆gt;详细信息

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

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

     与风险管理，广阔的视野   建筑的本质

编码时，首先要关注细节。然后你重点更广泛的重构。

  

建筑是关于领导力的。从后面领导很难

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

Answer 21

有偏离主题的风险......

在大型应用程序中，架构师可能无法使用正在编写的代码保持更新。此外，由于其他重要职责，他不可能编写代码。话虽如此，我建议，架构师不应该忽视正在开发的代码库的大局。这可以通过监控代码库的代码库，代码质量指标，静态代码分析等来实现。他应该使用上述标准定期评估代码质量。 “持续整合”的做法可以在这里提供帮助。

Answer 22

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

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

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