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

其实这文章没个大前提

编码,编什么类型的码?

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

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

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

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

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

成本！风险！

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

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

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

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

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

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

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

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

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

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

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

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