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

对于目前常见的开发，有哪个组长是专家？架构师对于需要涉足的领域没有足够的专业经验就不应该考虑相关的设计，而应该让有经验的人参与到设计当中才对，不能因为自己不够专业而降低架构设计的档次！

Rod的观点是非常正确的。

现在国内很多垃圾软件产生之技术根源有二：一是根本就没有系统架构设计的乌合编码；二是许多顶着“专家”或“架构师”称号的浪得虚名之徒瞎指挥。

既然是架构师,当然应该编写一些关键的代码.

我一直认为,一个程序都编不好的人，根本做不了什么架构和设计。

很有见地的话！

其实，我觉得架构不会与具体项目相关的，不会随项目随时变化。架构应该提供开发的基础平台，一旦确定了，程序员都在这上面做开发，针对不同的项目开发不同的业务模块就行了。所谓架构师的工作，就是确定这个平台，并随业界技术发展升级框架，提供通用业务组件支持。。。
我们一直是这样做的，不清楚其它公司的同仁们是否在统一平台上做开发，还是每个项目完全从头开始。。。

说得似乎是具体业务模块的设计吧？这是架构师的工作吗？

我看你不是没看过，而是没看懂

看清楚我说的，我哪句话说组长必须是专家了？！


再说又有谁说组长不能是专家了，都不知道你在反驳什么

你误解了，我前面说了架构工作会存在于整个开发过程，每个人都应该是架构师
我的意思是 像你这种顶着架构师头衔的人不是必需的

哦...，“每个人都是架构师”啊，受教受教

我倒是没发现我哪句话说自己是架构师了，你这人身攻击真挺没水平

我看这位小兄弟已经开始语无伦次了，我就不这儿跟你争了，免得等会儿再说自己是上帝

来自深圳，又有“SE”这个职位，楼主大概是H公司的吧？

实际上真正应该讨论的并不是SE或者说架构师要不要编码，而是这些拥有更丰富经验、拿着更高薪水的人应该如何承担更多责任、如何给比较junior的同事更多的指导和帮助。从这个角度来说，显然架构师不应该和developer一样从头到尾的把所有业务功能都实现出来。特别是像H公司这样的环境，SE有很多重要的事情要做。他们就应该只弄出足够指导developer的架构，然后投入下一个项目，不然就是浪费资源。

但另一方面，他们弄出的架构是“足够指导developer”的吗？我看H公司的很多developer并不这么认为。为了验证技术可行性，这些SE经常是在预研项目里把主要的业务功能都实现了一遍——用工程角度相当丑陋的方式。这个“丑陋”不是我说的，H公司的QA很清楚。这些预研实现通常都缺乏良好的编码风格，缺乏细节的异常考虑，缺乏测试，只是说大体流程能走通而已。其结果就是，developer拿到这个预研结果必须重新做实现，在工程角度“怎么做”的问题仍然缺乏指导。简而言之，这样的架构预研既有浪费，又有不足。

深挖下去就引申出另一个问题：到底什么是“架构”？只是验证了技术可行性、缺乏工程指导意义的架构是充分的吗？把所有主要功能都进行预研的架构设计是必要的吗？总是输出既不充分又不必要的架构设计，H公司倡导的这种“设计与实现分离”的工作方式本身是合理的吗？那些严格的质量流程都作用在developer身上，SE没有给developer足够的指导告诉他们如何遵循这个架构开发出符合质量要求的软件，最后developer被迫加班而SE因为架构设计而获奖，难道这是合理的吗？

照我的看法，一个架构设计只需要覆盖到最重要的技术难点，包含尽可能少的实现样板。另一方面，一个架构设计应该足够指导developer如何沿着这个架构继续工作，所以这个实现样板不仅要验证技术可行性，而且必须严格遵守组织的开发流程和质量要求，必须包含充分的测试。所以回到主题：架构师要不要编码？答案是：要，不需要像developer那么多，但必须以同样的工程方式来做，用同样的严格标准来要求，在开发过程中随时帮助developer解决技术难题和扶正方向，根据情况实时调整架构。这样developer才能沿着他开辟的道路继续走下去。这样才能真正体现出架构师对开发团队的指导作用。