第八章_敏捷协作_39 架构师必须写代码

39 架构师必须写代码

1. 问题是什么？

我们的系统需要一个什么样的架构师，需要一个什么样的设计方案？

2. 恶魔的方案

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

• 优点是什么？

  • 架构师工作量小，脱产，工作舒服

• 缺点是什么？

不可能再PowerPoint 幻灯片上进行编程

作为架构师，不应该只是画一些看起来很漂亮的设计图，说一些像“黑话”一样的词汇，使用一大堆设计模式——这样的设计通常是不会有效的。

他做了什么？

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

一个设计要解决的是眼前面临的特定问题，随着设计的实现，对问题的理解也会发生改变。想在开始实现之前，就做出一个很有效的详细设计是非常困难的（见习惯11）。

因为没有足够的上下文，能得到的反馈很少，甚至没有。

设计会随着时间而演进，如果忽略了应用的现状（它的具体实现），要想设计一个新的功能，或者完成某个功能的提升是不可能的。

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

夫子曰：纸上谈兵是不能打赢一场战役的，仅有计划是不行的。战略上的决策可以在后方进行，可是战术决策——影响成败的决策需要时刻对战场状况的深入了解。

只有一张蔬菜图无法做出好的咖喱菜。

3. 天使的方案

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

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

• 可逆性

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

• 新系统的设计者

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

纸上的设计也无法产生优秀的应用。应该根据设计开发出原型，经过测试，当然还有验证——它是要演化的。实现可用的设计，这是设计者或者说架构师的责任。

一个架构师应该指导开发团队，提升它们的水平，以解决更为复杂的问题。架构师最重要的任务：通过找到移除软件设计不可逆性的方式，从而去除所谓架构的概念。

增强可逆性是注重实效的软件实现方式的关键构成部分。

程序员在拒绝设计的同时，也就放弃了思考。

4. 切身感受

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

5. 平衡的艺术

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

6. 总结

夫子曰：

架构师不应该离开战场，也就是编码，离开了编码，就脱离了可以收到反馈消息的战场，就可能变成聋子，瞎子。所作的方案就有可能是无效的。

架构设计方案从时间角度来说，没有最终决策，要拥抱变化，增强可逆性是注重实效的软件实现方式的关键构成部分。

猛将必起于卒伍，宰相必起于州郡。