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

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

软件架构的坏名声

当我介绍自己是软件架构师时,对方通常会有两种反应。要么觉得这非常酷,想了解更多;要么就是露出不屑的神情,意思是说“我想跟实际开发软件的人聊,而不是跟只会画框框线线的指挥家聊”。软件架构的角色在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,测试驱动开发)替代画图。也就是说,假设他们已经不是只使用高层次系统隐喻的概念,而且也不把“浮现式设计”作为盲目乐观的借口。

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

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

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

失意的架构师

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

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