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

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

引用

   在我们的行业里，所谓“架构师”这个说法的准确含义是人么热辩的话题——同样，人们也在争论这个“架构师”概念（相对于“开发者”）到底有没有意思、是不是可取。
    我以为，架构师的作用非常重要，但是架构师们必须保持实际参与编码。如果他们脱离了生产第一线，仅仅满足于闭门造车式规定系统架构，那么他们也就时区了对许许多多的实际问题的接触，而正是这些实际问题决定了项目的最终成败。这种做法孕育着真正的危险。它是失败的温床，而且几乎总是导致过度的复杂性。不幸的是，很多人相信如果一个人在专业技术上获得了成功，他就应该最终完全脱离实际编码——这种观念很难根除，而且危害极深。
    对于软件的“架构”而言，实现架构时会遇到形形色色的问题，而解决这些问题则需要具体、详尽的细节知识；只有掌握了所有这些细节知识，才能够确定整个系统架构。所以，如果架构师把时间都花在编写文档、搭建模型上，那也就很难作出切实可用的架构。

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

评论

24 楼 tedeyang 2008-01-17  

认同楼上的观点。

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

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

23 楼 sonicluo3 2008-01-16  

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

22 楼 Godlikeme 2008-01-15  

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

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

21 楼 timerri 2008-01-15  

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

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

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

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

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

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

20 楼 fangshun 2008-01-15  

pufan 写道

成本！风险！

逐渐衍生出的设计很少能够一帆风顺的，推倒重来的可能性也是有的。

设计是一个效能问题，指望一帮人讨论出设计方向就好比长征需要全部红军投票决定南上还是北下一样，假若历史可以重来，我们现在就可能坐在新德里的办公大楼里讨论问题了，呵呵。

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

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

19 楼 daquan198163 2008-01-15  

其实问题的关键是
架构师要与程序员充分交流，表达自己的设计意图，最好的办法就是亲自写出一个原型
要能通过检查及时发现是否有人偏离了设计、违反了规范，最好的办法就是经常审查项目代码
程序代码是达到这些目的的最好手段，如果他不编码，难免要被架空

18 楼 xly_971223 2008-01-15  

不太同意楼主观点
架构师参与编码容易陷入技术细节 而忽略了对整体的把握
当然也不能一个代码不写 那样就严重脱离了实际 纸上谈兵
架构师要编码 编写那些系统核心级别 通用级别的代码

17 楼 robbin 2008-01-15  

做为规模比较小的项目，架构师没有什么理由不参加编码。但作为一个公司的首席架构师来说，未必有时间去参与编码，但即使是这种情况，架构师也必须经常和开发人员在项目细节上面进行充分的沟通，以掌握必要的情况。

16 楼 skydream 2008-01-15  

还有开发理念的问题，我个人是崇尚tdd的，一般我的程序都会有junit案例覆盖。拿webwork的action来说，我一般都是用junit来先测试通过再提交测试组测试的。

但是team中就是有其他人认为不必要，他们宁可选择将action直接放到resin下跑着测试，发现问题时就在eclipse启动resin用debug来查错。

不讨论是否合适的问题，只单从表面上看，如果架构要求做到测试友好，那么上面这种直接发布到webcontarner下去测试/debug的方法，就会直接挑战架构师的理念。

所有说每个成员都需要理解架构，很难很难。

15 楼 skydream 2008-01-15  

“架构应该是大家一起讨论、实验出的结果，每个成员都需要理解架构”

大家一起讨论，这个东西说起来容易，可是实现起来，除非这个team中的人员技术等级都相当并且编程习惯/理念都一致，否则简直不可想象。

一个team通常上有架构师，中间有高级工程师，底层有工程师和新人。这种情况下每个成员都需要理解架构简直是空话。最恶劣的情况，比如新人，技术差经验少，可能连oo都没有深刻理解，连junit都没有熟练，你怎么可能指望他达到理解架构的深度？

14 楼 pufan 2008-01-15  

daquan198163 写道

真的需要架构师么？
真的存在架构这项工作么？
我的意思是：
没必要要任命某个人专门做架构工作，然后其他人按照他做出的架构，继续开发
架构应该是大家一起讨论、实验出的结果，每个成员都需要理解架构
架构应该是随着开发逐渐衍生出来的，而不是预先设计出来的

成本！风险！

逐渐衍生出的设计很少能够一帆风顺的，推倒重来的可能性也是有的。

设计是一个效能问题，指望一帮人讨论出设计方向就好比长征需要全部红军投票决定南上还是北下一样，假若历史可以重来，我们现在就可能坐在新德里的办公大楼里讨论问题了，呵呵。

13 楼 javachs 2008-01-14  

我们这里也是设计的不编码，设计的无法实现，简单是从婴儿到坟墓一条线捅到底

12 楼 fangshun 2008-01-14  

daquan198163 写道

真的需要架构师么？
真的存在架构这项工作么？
我的意思是：
没必要要任命某个人专门做架构工作，然后其他人按照他做出的架构，继续开发
架构应该是大家一起讨论、实验出的结果，每个成员都需要理解架构
架构应该是随着开发逐渐衍生出来的，而不是预先设计出来的

同意！架构本身就是一个很不实际的定义，没有必要为了架构而去架构，软件的可塑性就已经决定了架构是需要在开发中不断构造的！

11 楼 daquan198163 2008-01-14  

真的需要架构师么？
真的存在架构这项工作么？
我的意思是：
没必要要任命某个人专门做架构工作，然后其他人按照他做出的架构，继续开发
架构应该是大家一起讨论、实验出的结果，每个成员都需要理解架构
架构应该是随着开发逐渐衍生出来的，而不是预先设计出来的

10 楼 jjx 2008-01-14  

其实这文章没个大前提

编码,编什么类型的码?

因为实际的应用系统代码有粗有细 ,面向领域多种多样,肯定需要有取舍

像spring 那种框架代码,保持持续编码其实更简单

9 楼 hantsy 2008-01-14  

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

8 楼 rasonyang 2008-01-14  

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

7 楼 weicanhuang 2008-01-13  

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

6 楼 galaxystar 2008-01-13  

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

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

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

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

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

5 楼 Godlikeme 2008-01-13  

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

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

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

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