应用程序架构师应该写代码吗？
这是一个双方都有看法的常被问到的问题。 赞成的人会说：
- 要为编码器devise一个系统，您必须了解如何编码（和编码）
- 你不能在没有意识到地面发生的事情的情况下devise一个系统
- 架构不仅仅是广泛的中风devise，而是适应代码级别不断变化的需求
另一方面，
- 架构是一个高层次的angular色，不应该关心实现细节
- 编码是一种与风险pipe理，build筑的广阔视野性质不相一致的细化导向，低调的function
- 架构是关于技术风险pipe理而不是实施
- build筑是关于领导力的。 从后面引路很困难
根据我的经验，架构师不应该花费大量时间编写代码，而是必须通过主要开发人员的沟通，回顾和站起来，与代码库保持联系。 如果你花了很多时间编码，就忽视了高层次的问题，在pipe理技术风险方面变得无效。
即使您反对编码的论点是有效的，我认为开发团队尊重您和您的devise决定是非常重要的。 如果您的架构决策与他们一起“承受后果”，那么他们不太可能质疑他们。
一直以来，我都看到与编码方无关的build筑师，以及开发团队都知道这一点。 他们没有得到很多的尊重。
AB-SO-frickin-lutely
没有什么比和现实失去联系的build筑师更糟了。
这是工作的一部分，保持你的脚在地上，你的头在云端。
只要给我两分钱（和我对“build筑师”的看法）
我相信有几种types的build筑师，每个在他们自己的领域：
-
业务和function架构师 ：他们关心的是业务操作和function工作stream程， 实际上他们不应该编写代码 ，因为他们必须能够从任何types的实现中抽象出自己，并且必须生成function规范 ，使技术解决scheme处于开放状态。
-
应用程序架构师 ：他们将function领域（如“利润和损失分析”）划分为应用程序（如“投资组合处理器”，“启动器”，“调度员”，“贵”）。 他们不需要编写代码，但他们应该是以前的编码人员 ，以便清楚地了解其架构必须解决的技术挑战。 他们的主要技能不是编码，而是倾听技术上的同事select正确的解决scheme。 然后他们将产生必须实施（编码）的技术实施 。
-
技术架构师 ：他们负责select和/或实施技术框架（对于任何function项目通用的框架，如KPI，日志logging，exceptionpipe理），他们应该绝对编码 （并且编码良好），因为他们的组件是所有其他function团队使用。
-
开发架构师 （嘿， 那就是我 ））：负责开发工具和stream程以及技术调查， 他们也应该编码和热爱编码 。
所以我相信不只有一个答案：它取决于你的build筑领域和专业知识：当涉及到“应用程序架构师”，我相信后三类可以有不同的编码经验…
我认为build筑的angular色正在改变。 我看到越来越less的象牙塔build筑师为低劣的程序员devise一个完整的系统来实现瀑布式的过程。
在做迭代项目时，build筑师和程序员之间的沟通变得更加重要。 架构师是团队的一部分，应该能够和程序员一起处理不断变化的需求和新想法。 在这样的情况下，build筑师和程序员的工作关系更密切。 我已经看到开发人员担任架构师angular色的团队能够为复杂的解决scheme提供经过深思熟虑的架构。
编辑在回复评论
我认为在应用程序，解决scheme和企业架构师之间的区别是有点人为的，并不适合于许多情况。 像安全架构师，数据架构师等angular色给责任之间的更清晰的消毒。 你可以在这里find更多的细节http://stevendwright.home.comcast.net/~stevendwright/ArchRoles.htm
顺便说一句，从再次读你的问题，我注意到，许多反对编码build筑师的论点似乎表明了build筑师强有力的pipe理/领导angular色。 我认为把pipe理angular色和架构angular色分开是个好主意。 最好让技术人员在编码和架构之间划分时间，而不是在pipe理和架构之间划分时间。
是。 多年没有编写代码的软件架构师会失去构build产品的现实。 他们开始生产具有更高抽象层次的macros伟devise，这些抽象层次似乎不断降低其发货date。
我所从事的每一个项目都包括一位架构师，他们没有花费大量的时间来处理代码，因为没有实际的知识，所以出现了问题。
那包括我当时那个build筑师的项目:-)
现在是个人大红旗。
我同意所有支持编码的build筑师的论点。 反对的论点不适合我。
代码需要抽象出应用程序中的高层次概念和低层次概念。 除非devise和代码在所有级别上集成，否则解决scheme将不尽如人意。
至于“编码是一种与风险pipe理，build筑的广阔视野性质不一致的详细导向的，低调的function” – 以我的经验来说，一个广泛的观点 – 特别是风险pipe理 – 使更好的编码者不会更糟:-)
“架构是关于技术风险pipe理，而不是实施” – 并非如此。 这是关于风险pipe理和实施（和其他一些东西）。
“架构是关于领导力的，很难从后面引导” – 为什么编码会让你落后？ 就我个人而言，我发现领导最好的地方是与你一起工作的人。
我（想我）是一个build筑师，编码是什么使这个工作的乐趣。
然后，你会发现你的想法即将到来，你可以看到你的devise工作，你可以看到devise中的错误（无论如何，太晚了，但下一次…）
是的，保持他们的编码经验。
有架构师，还有IT战略家。 如果你在多个部门领导一个涉及500人的整合项目，那么不会，这会阻碍你的发展。 如果你正在一个开发项目中领导几十人的devise和实现，那么是的。 否则，你将不太可能对与你的架构一起工作的日常现实有一个恰当的洞察力。
我不认为他们需要编写应用程序中的所有内容。 但是应该给他们一些任务。 有些“架构师”基本上是没有技术经验的黑客，他们把自己当作“传奇编码者”，devise系统，让你的工作量增加数周或数月，如果你没有架构的话，你将不得不这样做。 如果他们不能编写代码，他们就没有业务处于这个angular色……因为这个想法是一个架构，应该使应用程序更易于开发和维护。 但是，如果build筑师不能发展，他或她怎么会知道如何build造一个build筑？
而且，即使是最好的build筑师也做出错误的决定。 有时候白板上的东西看起来很棒，但实际上一个架构决策最终会让事情变得比原来要困难得多。 如果build筑师不得不吃自己的狗粮（并使用build筑），他们更倾向于纠正错误的决定，或build立围绕他们的方法。 另外通过触摸代码，他们至less有点熟悉它。 因此，如果开发人员在编码问题上遇到问题，那么架构师的眼光就不会因为开发人员的不满而黯然失色，并且认为开发人员做错了，却没有提供正确的解决方法。
架构师不需要在代码库中做大型项目。 但是他们至less应该在代码基础上做一些小的任务，迫使他们使用自己的架构。 另外，这些小任务可能会涉及到阅读很多其他人的代码，让他们了解人们如何使用这个架构，以及是否可以做任何事情来改进它。
正如Vlion所说，在一个被开发人员压倒性主导的社区中提出这个问题意味着答案将会倾向于“是”。
作为一个有“build筑师”职称的人，最近也被授予了“杰出工程师”的称号，我的忠诚被撕毁了。 总的来说，我认为编码通常不是build筑师时间的有效使用。 那我该怎么做？
- 了解业务。
- 了解用于启用业务的系统。
- 在IT战略和策略方面与业务合作。
- 确保目前的项目正在长期进行，项目经理专注于短期观点。
那么build筑师应该如何与现实保持联系呢？ 我认为通过定期会议和周转，只是与各个层面的人们交谈，并加油通信的轮子。
我认为，“实施细节”往往不是细节（当你考虑一些具体的实施问题时，会出现许多问题，仅仅作为细节，从“build筑”的angular度可以忽略不计）
应用程序架构师必须能够定义应用程序架构，devise应用程序，实现模式并指导其他人进行编码。 如果你不能做这些事情，那么你不是一个应用程序架构师。
有时候，他们必须编码。 例如，当团队只有一个人。
在我看来，他们可以编码，但不能失去大局。 不要去改变每天的devise结构。
你在编码网站上问这个问题。 你会基本上每个人都落在“是”的一面。
我的观点是肯定的，但仅仅足以跟上不断变化的需求
因为这里的每个人都是一个编码员，所以我最喜欢的就是地狱 – 是的答案 – 而且你不会对我产生任何分歧。
但是更好的答案在我看来是更正确的，因为它恰当地重视领域专业知识。 知道一点软件的人，但只是使用它是非常有价值的。
架构angular色如何划分似乎取决于组织的规模和性质。
如果我按照自己的方式，如果他们写出好的，有用的，详细的故事和用例，我会给客户一个故事build筑师的angular色。
只是将接口编写为代码？ 如果是这样，那么这是我期望从架构师那里得到的最低限度，而在其他情况下，它可能是更多的代码，例如带有方法存根的类。
架构是软件开发人员的核心技能。 可能有一些罕见的情况，当一个架构师不需要编写代码时是有意义的，但是我不记得以我自己的经验遇到过这样的场合。
build筑师必须对项目进行编码，或者至less对项目进行编码。 第二部分意味着他们必须能够使用其他团队使用的工具和技术进行编码。 （如果不继续编写代码，保持这些技能一定是非常困难的。）
最后，当build筑师负责select他人使用的工具和技术时，如果没有实际使用build议的工具，他们就无法做出这样的select。 在这种情况下，这位非编码devise师迅速退化成一位尖头老板，桌上摆着一堆小册子。
我想知道为什么没有人提到代码评论或配对编程可以取代编码。
与编码相比，我花更多的时间阅读代码并解决与同事有关的问题。 这使我对自己写的代码，结构和复杂性几乎有相同的理解，而且耗时更less。 当我编写代码时，我会为了好玩或探索新技术（这是我发现编码唯一有用的地方）。
架构是一个高层次的angular色，不应该关注实现>细节
代码是devise。 设想一个devise漂亮的build筑的build筑，但拒绝进入实施的细节，如何把合并出口，pipe道，电力，电梯或build立法律问题。
* Coding is a detailed oriented, heads-down funtion which is at odds具有风险pipe理，build筑学的广泛性
当你编码时，首先要关注细节。 然后你重新考虑更广泛的焦点。
build筑是关于领导力的。 从后面引路很困难
软件开发的战场是编码。 可能是产品经理或项目经理没有编码。 但build筑师需要这样做。 也许他应该花更多的时间来重构，显示代码可以有多好。 这样他以身作则。
对于偏离主题的风险…
在大规模应用程序中，build筑师可能无法保持正在编写的代码的更新。 而且，由于其他重要的责任，他不可能写代码。 话虽如此，我build议，架构师不应该放弃正在开发的代码库的大局。 这可以通过监视代码覆盖的代码库，代码质量度量，静态代码分析等来实现。他应该使用上述标准定期评估代码质量。 “持续整合”的做法可以帮到这里。
这个标准的开发者的回答是，一个build筑师也应该编码。 但是这是一种将技术放在第一位的开发者。 但我倾向于不同意。 是的，有一些编码技能是有益的，以便能够查看代码。
但是，build筑师所做的唯一事情就是将业务需求与实施结合在一起。 在我们的例子中的代码。 如果你的系统非常复杂，那么你不能同时编写代码和架构，因为你在不同的抽象层次上运行。
相反，你应该能够依靠开发人员。 他们应该能够描述实施的各个方面，以及它是如何适合你所指出的业务需求的。 select哪种技术是build筑师的决定，但要做出决定，他必须做研究或使用过去的经验。 这并不意味着他不会和开发人员交stream，也不会让他们调查一个特定的技术，看看架构是否真的有效。
