|
|
|
|
移动端

39 架构师必须写代码

《高效程序员的45个习惯:敏捷开发修炼之道》本书总结并生动地阐述了成为高效的开发人员所需具备的 45个习惯、思想观念和方法,涵盖了软件开发进程、编程和调试工作、开发者态度、项目和团队管理以及持续学习等几个方面。本节为大家介绍架构师必须写代码。

作者:钱安川/郑柯 译来源:人民邮电出版社|2010-03-04 08:57

年前最后一场技术盛宴 | 1月27日与京东、日志易技术大咖畅聊智能化运维发展趋势!


39 架构师必须写代码

"我们的专家级架构师Fred会提供设计好的架构,供你编写代码。他经验丰富,拿的薪水很高,所以不要用一些愚蠢的问题或者实现上的难点来浪费他的时间。"

软件开发业界中有许多挂着架构师称号的人。作为作者的我们不喜欢这个称号,为什么呢?架构师应该负责设计和指导,但是许多名片上印着"架构师"的人配不上这个称号。作为架构师,不应该只是画一些看起来很漂亮的设计图,说一些像"黑话"一样的词汇,使用一大堆设计模式--这样的设计通常不会有效的。

这些架构师通常在项目开始时介入,绘制各种各样的设计图,然后在重要的代码实现开始之前离开。有太多这种"PowerPoint架构师"了,由于得不到反馈,他们的架构设计工作也不会有很好的收效。

一个设计要解决的是眼前面临的特定问题,随着设计的实现,对问题的理解也会发生改变。想在开始实现之前,就做出一个很有效的详细设计是非常困难的(见第48页习惯11)。因为没有足够的上下文,能得到的反馈也很少,甚至没有。设计会随着时间而演进,如果忽略了应用的现状(它的具体实现),要想设计一个新的功能,或者完成某个功能的提升是不可能的。

作为设计人员,如果不能理解系统的具体细节,就不可能做出有效的设计。只通过一些高度概括的、粗略的设计图无法很好地理解系统。

这就像是尝试仅仅通过查看地图来指挥一场战役--一旦开打,仅有计划是不够的。战略上的决策也许可以在后方进行,但是战术决策--影响成败的决策需要对战场状况的明确了解。

可 逆 性

《程序员修炼之道》中指出不存在所谓的最终决策。没有哪个决策做出之后就是板上钉钉了。实际上,就时间性来看,不妨把每个重要的决策,都看作沙上堆砌的城堡,它们都是在变化之前所做出的预先规划。

新系统的设计者

新系统的设计者必须要亲自投入到实现中去。

--Donald E. Knuth

正像Knuth说的,好的设计者必须能够卷起袖子,加入开发队伍,毫不犹豫地参与实际编程。真正的架构师,如果不允许参与编码的话,他们会提出强烈的抗议。

有一句泰米尔谚语说:"只有一张蔬菜图无法做出好的咖喱菜。"与之类似,纸上的设计也无法产生优秀的应用。应该根据设计开发出原型,经过测试,当然还有验证--它是要演化的。实现可用的设计,这是设计者或者说架构师的责任。

Martin Fowler在题为"Who Needs an Architect?"  的文章中提到:一个真正的架构师"……应该指导开发团队,提升他们的水平,以解决更为复杂的问题"。他接着说:"我认为架构师最重要的任务是:通过找到移除软件设计不可逆性的方式,从而去除所谓架构的概念。"增强可逆性是注重实效的软件实现方式的关键构成部分。

要鼓励程序员参与设计。主力程序员应该试着担任架构师的角色,而且可以从事多种不同的角色。他会负责解决设计上的问题,同时也不会放弃编码的工作。如果开发人员不愿意承担设计的责任,要给他们配备一个有良好设计能力的人。程序员在拒绝设计的同时,也就放弃了思考。

优秀的设计从积极的程序员那里开始演化。积极的编程可以带来深入的理解。不要使用不愿意编程的架构师--不知道系统的真实情况,是无法展开设计的。

切身感受

架构、设计、编码和测试,这些工作给人的感觉就像是同一个活动--开发的不同方面。感觉它们彼此之间应该是不可分割的。

平衡的艺术

如果有一位首席架构师,他可能没有足够的时间来参与编码工作。还是要让他参与,但是别让他开发在项目关键路径上的、工作量最大的代码。

不要允许任何人单独进行设计,特别是你自己。

【责任编辑:云霞 TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

UNIX到Linux的移植

本书讲述怎样把UNIX环境下的应用程序移植到Linux环境上运行,是一本综合的开发和解决问题的参考手册 。本书详细描述了当前IT行业中被广泛应...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊