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