架构师要以自己的编程能为依托

作者：迈克·布朗

在架构上，架构师都期望能够创建出精巧的设计与完美的抽象，来优雅的解决手头上的问题。如果在项目中按插些新技术，那就更让人有成就感了。但是，最终要实现设计的不是架构师。如果开发人员需要去实现那些架构上的“杂技（acrobatics）”，那将会对整个项目造成巨大影响。

为项目设计架构时，对实现每个元素所需要的工作量，要做到心中有数；如果以前曾经开发过其中某个设计元素，那么估算所需工作量将会容易得多。

不要在设计里使用自己没有亲自实现过的模式，不要使用自己没有用之写过代码的框架，不要使用自己没有亲自配置过的服务器。如果架构依赖于各种你未曾亲身使用过的设计元素，那其中就存在许多负面影响：

• 对开发人员需经历的学习曲线，你将毫无经验。如果不清楚学习某种新技术所需要的时间，你也将无法很好预估实现设计所需要的时间。
• 对使用这些设计元素时要注意避免的陷阱（pitfall），你将一无所知。真正的实现，肯定不会像那些训练有素的专家所演示的那样完美。如果此前从未接触过这些技术，问题发生时你就钻入死胡同里无人应对了。
• 开发人员的信心将会深受打击。当他们向你询问设计相关的问题时，如果你无法给出确凿的答案，他们将很快对你和你的设计失去信心。
• 将会引入不必要的风险。不了解这些东西而在项目中盲目使用，就会在解决方案的关键元素上打上大大的问号。没人会愿意启动存在不必要的巨大风险的项目。

那么，架构师该如何学习新框架、新模式（pattern）和新的服务器平台呢？好，请参看另外一条格言：《架构师首先是开发人员》。