这是一个双方都有观点的常见问题。赞成的人会争辩：
另一方面，
根据我的经验，架构师不应该花费大量时间进行编码，而必须主要通过主要开发人员的沟通、审查和站立来与代码库保持联系。如果您花费大量时间进行编码，您就会忽略高层次的问题，从而无法有效地管理技术风险。
【问题讨论】：
标签： architecture
即使您反对编码的论点是有效的，我认为开发团队尊重您和您的设计决策也很重要。如果您与他们一起“承受架构决策的后果”，那么他们不太可能质疑他们。
一直以来，我看到架构师与编码方面脱节，而他们的开发团队知道这一点。他们没有得到太多尊重。
【讨论】：
Ab-so-frickin-lutely
没有什么比与现实脱节的建筑师更糟糕的了。
工作的一部分是让你的脚脚踏实地，让你的头在云端。
【讨论】：
只是为了给我两分钱（以及我对“建筑师”的看法）
我相信有几种类型的架构师，每一种都在自己的领域中：
业务和功能架构师：他们关心业务运营和功能工作流程，他们实际上不应该编码，因为他们必须能够将自己从任何类型的实现中抽象出来，并且他们必须制定功能规范，让技术解决方案保持开放。
应用架构师：他们将功能域（如“损益分析”）划分为应用程序（如“投资组合处理器”、“启动器”、“调度程序”、“gui” )。 他们不需要编码，但他们应该是以前的编码员，以便清楚地了解他们的架构必须解决的技术挑战。他们的主要技能不是编码，而是倾听技术同事的意见以选择正确的解决方案。然后，他们将产生必须实施（编码）的技术实施。
技术架构师：他们负责选择和/或实施技术框架（适用于任何功能项目的通用框架，如 KPI、日志记录、异常管理），并且他们 绝对应该编码（并且编码良好），因为它们的组件将被所有其他职能团队使用。
开发架构师（嘿，that's me ;)）：负责开发工具和流程以及技术调查，他们应该编码并热爱编码 也是如此。
所以我相信答案不只有一个：这取决于您的架构领域和专业知识：当谈到“应用程序架构师”时，我相信后三个类别可以有不同的编码经验......
【讨论】：
我认为建筑的角色正在发生变化。我看到越来越少的象牙塔架构师为低级程序员设计一个完整的系统以在瀑布过程中实现。
在进行迭代项目时，架构师和程序员之间的沟通变得更加重要。架构师是团队的一部分，应该能够与程序员一起处理不断变化的需求和新想法。在这种情况下，架构师和程序员的工作关系更密切。我见过开发主管担任架构师角色的团队，他们为非常复杂的解决方案提供经过深思熟虑的架构。
编辑回复评论
我认为在应用程序、解决方案和企业架构师之间的区别有点人为，在很多情况下并不真正适合。安全架构师、数据架构师等角色在职责之间提供了更清晰的区分。您可以在这里查看更多详细信息http://stevendwright.home.comcast.net/~stevendwright/ArchRoles.htm
顺便说一句，再次阅读您的问题后，我注意到许多反对编码架构师的论点似乎表明架构师具有强大的管理/领导角色。我认为将管理和架构角色分开是个好主意。让您的技术人员将他们的时间分配给编码和架构，而不是管理和架构。
【讨论】：
是的。多年未编写代码的软件架构师与构建产品的现实失去了联系。他们开始制作具有更高抽象级别的宏伟设计，这似乎一直在推迟他们的发货日期。
【讨论】：
我参与过的每个项目都包括一位架构师，他没有将大部分时间花在代码上，由于缺乏实践知识，因此遇到了问题。
这包括我担任建筑师的项目 :-)
现在是个人的大红旗。
我同意所有支持编码架构师的论点。反对的论点对我来说并不好。
代码需要抽象应用程序中的高级概念和低级概念。除非设计和代码在所有级别上集成，否则解决方案将不是最佳的。
至于“编码是一种面向细节的、低头的功能，这与风险管理、架构的宽广视角性质不一致”——根据我的经验，这是一种宽广的视角——尤其是风险管理——让编码人员变得更好而不是更差:-)
“架构是关于技术风险管理，而不是实施”——并非如此。这是关于风险管理和实施（以及一堆其他东西）。
“架构是关于领导力的。很难从后面领导”——为什么编码会让你落后？就我个人而言，我发现最好的领导方式是和你一起工作的人在一起。
【讨论】：
我（我认为我）是一名建筑师，编码是这份工作的乐趣所在。
然后您会看到您的想法正在变为现实，您可以看到您的设计正在运行，并且您可以看到设计中的错误（无论如何为时已晚，但下一次......）
【讨论】：
是的，以保持他们的编码经验。
【讨论】：
有架构师，也有 IT 战略家。如果您正在领导一个涉及多个部门的 500 人的集成项目，那么不，它会妨碍您。如果您在一个开发项目中领导多达几十个人的设计和实施，那么可以。否则，您将不太可能对使用架构的日常现实有适当的洞察力。
【讨论】：
我认为他们不需要对应用程序中的所有内容进行编码。但是应该给他们一些任务。一些“架构师”基本上是没有技术经验的黑客，他们将自己伪装成“传奇编码员”和设计系统，如果你没有架构，你将不得不做的工作量增加数周或数月。如果他们不能编写代码，他们就没有这个角色的业务......因为这个想法是一个架构应该使应用程序更容易开发和维护。但是如果架构师不能开发，他或她怎么知道如何制作架构？
此外，即使是最好的架构师也会做出错误的决定。有时某些东西在白板上看起来很棒，但实际上架构决策最终使事情变得比应有的困难得多。如果架构师不得不吃他/她自己的狗粮（并使用架构），他们更倾向于想要纠正错误的决定或围绕它们设计方法。同样通过触摸代码，他们至少对它有点熟悉。因此，如果开发人员带着编码问题来找他们，架构师的眼睛不会呆滞，因为他/她解雇了开发人员并说开发人员做错了，但没有提供关于正确方法的见解。
架构师不需要在代码库中进行大型项目。但他们至少应该在代码库中做一些小任务，迫使他们使用自己的架构。此外，小任务可能会涉及阅读大量其他人的代码，以让他们了解人们如何使用该架构以及是否可以做任何事情来改进它。
【讨论】：
正如 Vlion 所说，在一个以开发人员为主的社区中提出这个问题意味着答案将倾向于“是”。
作为一个在职称中有“建筑师”但最近还获得了“杰出工程师”徽章的人，我的忠诚被撕裂了。总的来说，我认为编码通常不能有效地利用架构师的时间。那我该怎么办？
那么建筑师应该如何与现实保持联系呢？我认为通过定期会议和走访，只是与各个级别的人交谈并为沟通的轮子加油。
【讨论】：
我开始相信，“实现细节”通常不是细节（从某种意义上说，当您将某些特定的实现问题视为可以被视为“建筑”视角）
【讨论】：
应用程序架构师必须能够定义应用程序架构、设计应用程序、实施模式并指导其他人编写代码。如果你不能做这些事情，那么你就不是应用程序架构师。
【讨论】：
有时，他们必须编码。例如，当团队只有一个人时。
在我看来，他们可以根据需要编写代码，但不能丢失大局。每天都改变设计的结构是不行的。
【讨论】：
你是在一个编码网站上问这个的。你会让基本上每个人都支持“是”。
我的观点是，是的，但仅足以跟上不断变化的需求，仅此而已
【讨论】：
由于这里的每个人都是编码员，所以最喜欢的肯定是地狱-是的答案-我不会有任何不同意见。
但我认为finer grained answer 更正确，因为它适当地重视领域专业知识。对软件知之甚少但只是使用它的人是如此宝贵。
架构角色的划分方式似乎取决于组织的规模和性质。
如果我按照自己的方式去做，我会给客户一个故事架构师的角色，如果他们写出好的、有用的、详细的故事和用例。
【讨论】：
只编写接口算作代码吗？如果是这样，那么这是我对架构师的最低期望，而在其他情况下，他们可能会提供更多代码，例如带有方法存根的类。
【讨论】：
架构是软件开发人员的核心技能。对于架构师来说，不编码可能有一些罕见的情况，但我不记得在我自己的经验中遇到过这样的情况。
架构师必须在项目中编写代码，或者至少完全能够编写项目代码。第二部分意味着他们必须能够使用团队其他成员使用的工具和技术进行编码。 （不继续写代码，要保持这些技能肯定是非常困难的。）
最后，当架构师负责选择其他人使用的工具和技术时，如果不实际使用建议的工具，他们就无法很好地做出这样的选择。在这种情况下，非编码架构师迅速退化为一个尖头发的老板，办公桌上放着一堆小册子。
【讨论】：
我想知道为什么没有人提到可以替代编码的代码审查或结对编程。
与编写代码相比，我花更多的时间阅读代码并与同事一起解决问题。这让我对代码、其结构和复杂性的理解与自己编写几乎相同，而且耗时少得多。当我编码时，我这样做是为了好玩或探索新技术（这是我发现编码有用的唯一地方）。
【讨论】：
架构是一个高级角色，不应该关心实现>细节
代码就是设计。想象一下，一位建筑师设计了漂亮的建筑，但拒绝进入实施细节，例如在哪里放置紧急出口、管道、电力、电梯或建筑法律问题。
* Coding is a detailed oriented, heads-down funtion which is at odds具有风险管理，视野开阔 建筑的本质
在编写代码时，首先要关注细节。然后你以更广泛的关注点进行重构。
架构是关于领导力的。后面很难带路
软件开发的前线是编码。可能是产品经理或者项目经理不会编码。但是建筑师需要这样做。也许他应该花更多的时间重构来展示代码有多好。这样，他以身作则。
【讨论】：
冒着偏离主题的风险……
在大型应用程序中，架构师可能无法及时了解正在编写的代码。此外，由于其他重要职责，他不可能编写代码。话虽如此，我还是建议架构师不要放弃正在开发的代码库的大局。这可以通过监控代码库的代码覆盖率、代码质量指标、静态代码分析等来实现。他应该使用上述标准定期评估代码质量。 “持续集成”的做法在这里可以提供帮助。
【讨论】：
这个标准的开发人员回答是架构师也应该编码。但它是一种将技术放在首位的开发者。但我倾向于不同意。是的，拥有一些编码技能是有益的，以便能够审查代码。
但架构师唯一要做的就是将业务需求与实施结合起来。在我们的例子中是代码。如果你有一个非常复杂的系统，你不能同时编码和做架构，因为你在太多不同的抽象级别上操作。
相反，您应该能够依赖开发人员。他们应该能够描述实现的各个方面，以及它如何适应您向他们指出的业务需求。选择什么技术是建筑师的决定，但要做出这个决定，他必须进行研究或利用过去的经验。这并不意味着他不与开发人员交谈，或者让他们研究特定技术以查看架构是否真的有效。
【讨论】：