这是一个经常被问到的问题,双方都有意见.赞成的人会争辩说:
要为编码器设计系统,您必须了解如何编码(并进行编码)
如果不了解地面发生的情况,就无法设计系统
架构不仅涉及宽中风设计,还涉及适应代码级别不断变化的需求
另一方面,
架构是一个高级角色,不应该关注实现细节
编码是一种详细的,低调的功能,与风险管理,建筑的广阔视野不一致
架构是关于技术风险管理而不是实施
建筑是关于领导力的.从后面领导很难
根据我的经验,架构师不应该花费大量时间编写代码,但必须主要通过主要的开发人员沟通,审查和站立来与代码库保持联系.如果您花费大量时间进行编码,则会忽视高级别问题,并无法有效管理技术风险.
即使您反对编码的论点有效,我认为开发团队尊重您和您的设计决策也很重要.如果"承担后果"的与他们一起的架构决策,那么他们太多不太可能问他们.
我总是看到那些与编码方面脱节的建筑师,他们的开发团队都知道它.他们没有得到太多的尊重.
AB-SO-frickin-lutely
没有什么比一个与现实失去联系的建筑师更糟糕的了.
将脚放在地上,将头放在云端,这是工作的一部分.
只是为了给我两分钱(以及我对"建筑师"的看法)
我相信有几种类型的架构师,每个都在他们自己的域中:
业务和功能架构师:他们关注业务运营和职能工作流程,他们实际上不应该编码,因为他们必须能够从任何类型的实现中抽象自己,并且他们必须生成功能规范,使技术解决方案保持开放.
应用架构师:他们将功能域(如"盈亏分析")划分为应用程序(如"组合处理器","启动器","调度员","gui").他们不需要编码,但他们应该是前编码器,以便清楚地了解他们的架构必须解决的技术挑战.他们的主要技能不是编码,而是倾听技术同事以选择正确的解决方案.然后,他们将产生必须实施(编码)的技术实施.
技术架构师:他们负责选择和/或实施技术框架(对于任何功能项目都是通用的,如KPI,日志记录,异常管理),并且它们应该绝对编码(并且编码良好),因为它们的组件将是所有其他职能团队使用.
开发架构师(嘿,就是我 ;)):负责开发工具和流程,以及技术调查,他们应该编码并喜欢编码.
所以我相信不只有一个答案:它取决于你的建筑领域和专业知识:当涉及到"应用程序架构师"时,我相信后三个类别可以有不同的编码经验......
我认为架构的作用正在发生变化.我看到越来越少的象牙塔建筑师为低级程序员设计一个完整的系统,以便在瀑布流程中实现.
在进行迭代项目时,架构师和程序员之间的沟通变得更加重要.架构师是团队的一员,应该能够与程序员一起处理不断变化的需求和新想法.在这种情况下,建筑师和程序员的工作关系更密切.我见过开发人员扮演建筑师角色的团队为非常复杂的解决方案提供了经过深思熟虑的架构.
编辑在回复评论时
我认为在应用程序,解决方案和企业架构师之间的区别有点人为,并且在很多情况下并不适合.安全架构师,数据架构师等角色可以更清楚地消除责任.你可以在这里查看更多详情http://stevendwright.home.comcast.net/~stevendwright/ArchRoles.htm
顺便说一句,从再次阅读你的问题,我注意到许多反对编码架构师的论据似乎表明了建筑师的强大管理/领导角色.我认为将管理和架构角色分开是个好主意.最好让技术人员在编码和架构之间划分时间,而不是在管理和架构之间划分时间.
是.多年未编写代码的软件架构师失去了构建产品的现实.他们开始制作具有越来越高抽象水平的宏伟设计,这似乎会使他们的出货日期不断下滑.
我所参与的每个项目都包括一个没有花费大量时间的建筑师,因为没有实践知识,代码就会出现问题.
那包括我是那个建筑师的项目:-)
它现在是个人大红旗.
我同意支持编码的架构师的所有论点.反对的论点不适合我.
代码需要抽象高级概念以及应用程序中的低级概念.除非设计和代码集成在所有级别,否则解决方案将不是最佳的.
至于"编码是一个详细的导向,低调的功能,与风险管理,建筑的广阔视野不一致" - 根据我的经验,广泛的观点 - 尤其是风险管理 - 使更好的编码员不会更糟:-)
"架构是关于技术风险管理而不是实施" - 事实并非如此.这是关于风险管理和实施(以及其他一些东西).
"建筑是关于领导力的.很难从后面领导" - 为什么编码会让你落后？就个人而言,我发现最好的领导地点是与你一起工作的人.
我(我想)我是一名建筑师,编码是让这项工作变得有趣的原因.
然后你看到你的想法变得生动,你可以看到你的设计工作,你可以看到设计中的错误(无论如何都太晚了,但下次......)
是的,保持他们的编码经验.
有建筑师和IT战略家.如果您正在领导一个涉及多个部门500人的集成项目,那么不会,这会妨碍您.如果您在开发项目中领导多达几十人的设计和实施,那么是的.否则,您将不太可能对使用您的架构的日常现实有适当的了解.
我不认为他们需要编写应用程序中的所有内容.但他们应该得到一些任务.一些"架构师"基本上是没有技术经验的黑客,他们将自己视为"传奇编码员"和设计系统,如果你没有架构,你可以增加数周或数月的工作量.如果他们无法编写代码,那么他们就没有业务在这个角色......因为这个想法是一个架构应该使应用程序更容易开发和维护.但如果建筑师无法发展,他或她将如何知道如何建造建筑？
而且,即使是最好的建筑师也会做出糟糕的决定.有时在白板上看起来很棒,但实际上,架构决策最终会使事情变得比应有的更难.如果建筑师必须吃他/她自己的狗食(并使用建筑),他们更倾向于想要纠正错误的决定或围绕他们设计方法.通过触摸代码,他们至少有点熟悉它.因此,如果开发人员遇到编码问题,建筑师的眼睛就不会因为他/她解雇开发人员并且说开发人员做错了,但没有透露正确的方法.
架构师不需要在代码库中做大项目.但他们至少应该在代码库中执行小任务,迫使他们使用自己的架构.此外,小任务可能涉及阅读许多其他人的代码,以使他们了解人们如何使用该架构,以及是否可以采取任何措施来改进它.
京公网安备 11010802040832号 | 京ICP备19059560号-6 