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

在Rod Johnson的《expert one-on-one J2EE Development without EJB》一书中，有这么一段话：


说得太好了！
我们部门的SE们好象都有不参与实际编码的不良习惯 。

SE不参与编码，那要他们做什么？

多幸福啊的架构师啊。

我们部门现在是架构师/设计师/程序员/页面开发，统统全包，还要负责需求分析，简单是从婴儿到坟墓一条线捅到底。

基本同意LZ观点，但有点不同。
即便没有参与实际编码，但只要始终保持对系统开发趋势的把控，对系统构件和技术做到了然于胸，我以为也是可以的。

因为，一但参与了具体编码，在正常开发阶段没有问题，不过一但出现了紧急的技术问题或构架问题，SE就两难顾了。

因此，即便参与编码，适当就好、点到为止。

有些工作了10余年的架构师，难道还让他们编码不成？

架构是针对某个系统，某个项目，或者是某几个项目的，是要从总体上考虑问题、解决问题的，职责中注定要了解具体问题，这种具体问题说白了就是技术实现，如果不编码至少也要接触代码。

说到编码很可能指的是了解具体情况即可，不一定是让他开发一个业务模块。当然在一个小的团队架构应该也是什么都做的。但说到这里一般来说，身为架构如果不编码肯定是有问题的，容易被下面的人忽悠住，在一些关键问题上不太好做判断。

工作10余年和是否编码没有关系吧，编程10年以上的人还是挺多的，只是工作分量的问题。
生有崖而知无涯。
专业程序员不把是否coding 作为自己水平的指标，而把是否持续coding 作为一种职业素养。

架构师是要对系统负责的，还有一种可能不用负什么责任，技术顾问，只给出建议意见，具体还应该是架构去做。

工作10余年的架构师，还在编码的，非常少见。至少在我身边 :）

而他的职责，在于提意见，评审技术方案，在经验上给予支持。
最重要的是，他需要带年轻的架构师。因为实际上战场的一定是他们。

年轻架构师，有几个特点：
1，精力会比较旺盛，什么事情都想设计到非常完美而导致过渡设计。
2，对某一方面非常精通，但在自己的弱项时，因为顶着架构师的头衔，而硬着头皮去啃。这点，PM没法说服他，只能让比他更猛的人来教导。
3，喜欢用新技术，并且自己比较有自信。可能自己写过几个test case，从主观角度无法发现问题。
。。。

这个时候，他需要适当指正这些问题。

他不用编码，也能对整个项目起到决定作用。
从某些角度来说，应该这种人归类到技术顾问。但在大多数公司的职位还是架构师。：）

支持，架构师要参与编码，但重点在把握全局技术应用和实现，不是跟下面的人 比谁开发快，比谁开发多。

我非常认同！架构师一定要参与编码，但编码量不宜过大，最好参与业务最负责、技术难度最大的功能模块的编码。
对系统架构是非常有好处的！
我对这深有体会！

中国的现状，可以用可悲来形容，大多数项目经理，架构师，分析人员都是做了一两年程序起来的，可以说大多数很多人还不是一个合格的程序员，对项目的把握可想而知。