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

Question

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

要为编码器设计一个系统，您必须了解如何编码(并正在编码) level

• Architecture

• 您无法在不了解地面上发生的事情的情况下设计一个系统，这不仅是为了广泛的笔画设计，而且是为了适应在代码级别上不断变化的需求。

另一方面，

details

• Coding是一个高层次的角色，不应该关注architecture

• Architecture的实现，它是一个面向细节的、与风险管理不一致的头向下的功能，architecture

• Architecture的广义性质是关于技术风险管理，而不是implementation

• Architecture是关于领导力。很难从

的背后领导

在我的经验中，架构师不应该花费大量的时间编写代码，而必须主要通过主要的开发人员交流、审查和站起来来与代码库保持联系。如果您花费大量的时间编写代码，您就会忽略高级别的问题，并且在管理技术风险方面变得无效。

Answer 1

即使您反对编码的论点是正确的，我也认为开发团队尊重您和您的设计决策是很重要的。如果您“承受”架构决策带来的后果，那么它们就不太可能对它们提出质疑。

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

Answer 2

Ab-so-frickin-lutely

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

这是工作的一部分，让你的脚在地面上，你的头在云中。

Answer 3

只是为了给我两分钱(和我对“建筑师”的愿景)

我相信有几种类型的建筑师，每一种都属于他们自己的领域：

• business和functional ：他们关注业务操作和功能工作流，他们实际上不应该编写代码，因为他们必须能够将自己从任何类型的实现中抽象出来，而且他们必须生成功能规范，这使得技术解决方案open.
• applicative架构师：他们将功能域(如“盈亏分析”)划分为应用程序(如“组合处理器”、“启动程序”、"dispatcher“、"gui")。--他们不需要编码，但是他们应该是前程序员，这样才能清楚地了解他们的体系结构必须解决的技术挑战。他们的主要技能不是编码，而是倾听技术同事的意见，以便选择正确的解决方案。然后，他们将产生必须实现的(coded).
• technical架构师的技术实现:他们负责选择和/或实现技术框架(那些对于任何功能项目都是通用的，如KPI、日志记录、异常管理)，并且绝对应该编写代码(并且代码很好)，因为它们的组件将被所有其他的功能teams.
• development架构师使用(嘿，that's me；)：负责开发工具和过程，以及技术调查，他们也应该编码和喜欢编码。

因此，我认为不只是一个答案:它取决于您的架构领域和专业知识:当涉及到“应用程序架构师”时，我相信后三个类别可能有不同的编码经验……