【转载】优秀程序员的45个习惯之39——架构师必须写代码

架构师必须写代码

——   高效程序员的 45 个习惯之习惯39

 

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

 

 

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

 

不可能在PowerPoint 幻灯片中进行编程                You can’t code in PowerPoint

 

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

 

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

 

作为设计人员，如果不能理解系统的具体 细节，就不可能做出有效的设计。只通过一些高度概括的、粗略的设计图是没有办法达成对系统的理解的。

 

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

 

可　逆　性

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

 

新系统的设计者  Donald E. Knuth

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

 

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

 

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

 

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

 

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

 

优秀的设计从积极的程序员那里开始演化

积极的编程可以带来深入的理解。不要使用不愿意编程的架构师——不知道系统的真实情况，是无法展开设计 的。

 

切身感受

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

平衡的艺术

• 如果有一个首席架构师，他可能没有足够的时间来参与编码工作。还是要让他参与，但是别让他开发 在项目关键路径上的、工作量最大的代码。
• 不要允许任何人单独进行设计，特别是你自己。

摘自：http://turingbooks.iteye.com/blog/559023