Rod Johnson：架构师必须保持实际参与编码

极限的目的就是让设计在开发中逐渐衍生出来，所以并不是你所说的“很少能够一帆风顺”！

但是我可以肯定设计者不进行编码而进行的项目，系统肯定是脆弱的，软件系统内部的胶合剂是设计阶段不可估计的！

唉，这个问题其实讨论反了。不应该是讨论架构师该不该去编码，而是应该讨论如果程序员不能完成架构师构想的编码的时候，架构师该怎么办。

如果架构师的思想程序员能够完全理解并且实现的话，架构师何须去编码呢？

如果一个团队能对项目有统一的理解并能统一实现策略的话，那又何须有架构师呢？

可惜，上面的2个如果都是不现实的。
所以，架构师还是要存在，架构师还是要编码。

与其程序员与架构师互相指责，不如好好考虑磨合的问题，程序员多理解下架构师的思想，架构师多引导下程序员的编码......如果两方都等着对方多做事情，那事情恐怕就是做不成的了！！

另：如果架构师自己都实现不了自己的设计的话，或者设计出的东西本身就是错的话，那么这种架构师不要也罢....

首席架构师是一个顾问性质，对下面的年轻架构师给出指导建议，参与一些重要决策，并不负责具体的项目。
对他们来说，编码是个人习惯，不是具体工作。

架构不是一个职位，是一种职责，解决系统关键设计问题，所以他不一定是一个特定的人，也不定是团队中特定的角色。
设计是一个过程，没错。软件设计很多思想来源于建筑，包括架构这一词，但即使建筑也不光是预先设计的产物。

我个人觉得 Rod Johnson 的意思是架构师长期不参与编码的话会造成设计理念与实际生产之间有误差,这点会影响到整个项目或者以后的项目.

认同楼上的观点。

我们公司曾经犯过这样的错误，让一位技术高手在不很了解某个业务领域的情况去重新设计一个框架，而这位高手刚到公司没多久，设计开发过程中也没有和该领域的实际开发人员真正沟通，结果可想而知：过度设计、不实用！
这个框架在完成beta版后就被束之高阁了，以前的开发人员自己重构了代码，很愉快地用到现在...

如果架构师不能通关所有细节，那么设计必然会存在这样那样的问题，也许就会造成严重后果。
做好设计真的需要非常丰富的经验并经历艰苦的思考和抉择。
有实际编码经验和开发过程的体验对架构师很重要。

讨论是必须的，架构师不可能比每个专业领域的专家都更专业，同时也需要开发组的组长理解设计意图
架构师也是必须的，估计这位小伙子没开发过什么大型项目

只能说架构师不能完全不去写代码，但是架构师如果在工作中过多的编码，就会将思想局限在某个局部上了。我以为架构的编码可以以测试性质的编码和独立于项目而存在，即跟上了新型的编程方法，也能适当的解决问题。最主要的还是思想的高度仍然站在整体的层次上~~

估计这位老先生没看过Rod Johnson的那两本书

ps：这年头，架构师不是什么好听的称呼了

架构师也必须了解系统业务流程，也许不要很精通，但是基本的了解是必须的。
如果在项目组讨论的时候，开发人员说的业务术语都不知道，怎么可能设计出一个适用的系统架构。

请把编码分成 自己实验性编码和参与项目编码两种。

我认为Rod是指前者，而非后者。