序

信息技术行业不是大步前行，就是剧烈动荡。一方面，我们奋力前行，重新发明软件构建方式，时时处处精益求精。而另一方面，我们不断遗忘过去的好处，软件开发团队常意想不到地把事情搞砸。

软件架构在一个成功的软件交付中扮演关键角色，然而令人沮丧的是，很多团队都忽视了这一点。即使在最敏捷的团队中，软件构架这一角色也都是必需的，不管是由一个人还是整个团队共同扮演，但要寻求到预先和演化两种构架理念的平衡，往往还只是人们美好的意愿而并没有变为现实。

软件架构的坏名声

当我介绍自己是软件架构师时，对方通常会有两种反应。要么觉得这非常酷，想了解更多；要么就是露出不屑的神情，意思是说“我想跟实际开发软件的人聊，而不是跟只会画框框线线的指挥家聊”。软件架构的角色在IT行业中名声很差，出现这种想法自然不难理解。

“软件架构”给人的印象通常是架构师闭门造车，提前做好大型预先设计，然后好像接力赛跑时传递交接棒一样，把庞大的UML（Unified Modeling Language，统一建模语言）模型或200页Word文档丢给毫不知情的开发团队。当然，这是假设架构师实际参与了软件设计。似乎很多人都认为，只要做一个PPT，而且幻灯片中有一页出现了“企业服务总线”框线图，就算是做完了软件设计。哦，千万别忘了，这个PPT里毫无疑问也少不了对ROI（Return on Investment，投资回报）和TCO（Total Cost of Ownership，总体拥有成本）的陈述。

很多组织对软件开发普遍都有一个有意思的看法。比如，他们看到了离岸外包可以节省成本，因而把软件开发流程中的编码工作也看作一种可以买卖的商品。其结果往往是本地开发者被推向所谓“高价值”的软件架构职位，而编码则交由其他人完成。多数情况下这只会让软件架构和开发更加脱节，还常常让人像赶鸭子上架一样不得不去承担架构工作。这些组织也常倾向于把架构师看作一种职位级别而非工作角色。

敏捷愿景

“敏捷”已经出现了差不多十年，但它仍是“外来的时髦小子”。很多软件团队都有“实现敏捷”的愿景。毫无疑问，敏捷有很多好处，人们都想让你相信它是灵丹妙药，但事实并非如此。IT行业的每件事，都伴随着铺天盖地的宣传和天花乱坠的炒作。如今，开始一个新的软件项目，总能听到自组织的团队、自动化验收测试、持续交付、回顾、看板、浮现式设计，还有一大堆你可能都没听过的新名词。这很奇葩，但团队往往急于赶时髦，就将原来的东西不分好坏一起丢掉。“非功能需求”听起来虽然不酷，但这并不是你能忽视它们的理由。

这堆老古董软件架构的东西都是什么？很多软件团队似乎认为他们不需要软件架构师，张口闭口都是“自组织团队”、“YAGNI”（You Aren't Going to Need It，你不会需要它）、“演化架构”和“最后责任时刻”这些词。如果他们确实需要架构师，也许会去找个“敏捷架构师”。我不完全确定这些词都是什么意思，但我猜它有点像用便利贴替代UML，或用TDD（Test-Driven Development，测试驱动开发）替代画图。也就是说，假设他们已经不是只使用高层次系统隐喻的概念，而且也不把“浮现式设计”作为盲目乐观的借口。

那么你觉得自己是架构师吗

看起来这个行业里有很多人自称是软件架构师，而他们实际上完全在做别的事。我能够原谅那些在大企业里实践软件架构，却误以为自己是“企业架构师”的人。总之我们这行的术语就是经常把人搞糊涂。

但那些夸大自己在软件团队里作用的人又如何呢？这些不负责任的架构师通常担任技术领导，却连基本能力都不够格。我见过一些面向公众的网站在进入用户验收测试环境时，还有一堆安全问题，没有基本性能测试，常用功能也有问题，死链，并且完全没有文档。这只是我能看到的软件外在的问题，天知道代码会是什么样子！如果你承担了软件架构的角色，最后却交付这样的东西，你做得就不对。这不是什么软件架构，这也只能算是盲目乐观。

失意的架构师

必须承认，不是所有软件团队都像这样，但我前面讲的也不是空穴来风。糟糕的是很多组织确实就是这样干的，因此软件架构有这样的名声并不奇怪。

想在这个行业里有所作为，就需要克制对新鲜玩意的迷恋，开始问一些问题。敏捷需要架构吗，或者架构真的需要敏捷吗？相比近些年学到的东西，我们是不是忘掉了更多好的软件设计方法？对于我们现在构建的软件系统，只有盲目乐观就够了吗？如果我们不是从培养未来软件架构师的角度考虑，这些问题还有意义吗？我们要如何从失意走向平和？