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

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

软件架构的坏名声

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

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

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

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

失意的架构师

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

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

目录

  • 版权声明
  • 献词
  • 推荐序一:架构师真正要学会的事情
  • 推荐序二
  • 译者序2.0
  • 关于本书
  • 软件架构培训
  • Part Ⅰ 什么是软件架构
  • 第 1 章 什么是架构
  • 第 2 章 架构的种类
  • 第 3 章 软件架构是什么
  • 第 4 章 敏捷软件架构是什么
  • 第 5 章 架构对上设计
  • 第 6 章 软件架构重要吗
  • 第 7 章 问题
  • Part Ⅱ 软件架构的角色
  • 第 8 章 软件架构的角色
  • 第 9 章 软件架构师应该编码吗
  • 第 10 章 软件架构师应该是建造大师
  • 第 11 章 从开发者到架构师
  • 第 12 章 拓展T
  • 第 13 章 软技能
  • 第 14 章 软件架构不是接力运动
  • 第 15 章 软件架构要引入控制吗
  • 第 16 章 小心鸿沟
  • 第 17 章 未来的软件架构师在哪里
  • 第 18 章 每个人都是架构师,除非他们有其他身份
  • 第 19 章 软件架构咨询师
  • 第 20 章 问题
  • Part Ⅲ 设计软件
  • 第 21 章 架构驱动力
  • 第 22 章 质量属性(非功能需求)
  • 第 23 章 处理非功能需求
  • 第 24 章 约束
  • 第 25 章 原则
  • 第 26 章 技术不是实现细节
  • 第 27 章 更多分层等于更高复杂度
  • 第 28 章 协同设计是一把双刃剑
  • 第 29 章 软件架构是对话的平台
  • 第 30 章 SharePoint项目也需要软件架构
  • 第 31 章 问题
  • Part Ⅳ 可视化软件
  • 第 32 章 沟通障碍
  • 第 33 章 对草图的需要
  • 第 34 章 无效的草图
  • 第 35 章 C4:语境、容器、组件和类
  • 第 36 章 语境图
  • 第 37 章 容器图
  • 第 38 章 组件图
  • 第 39 章 是否包含技术选择
  • 第 40 章 你会那样编码吗
  • 第 41 章 软件架构和编码
  • 第 42 章 你不需要UML工具
  • 第 43 章 有效的草图
  • 第 44 章 C4的常见问题
  • 第 45 章 问题
  • Part Ⅴ 为软件生成文档
  • 第 46 章 代码不会讲述完整的故事
  • 第 47 章 软件文档即指南
  • 第 48 章 语境
  • 第 49 章 功能性概览
  • 第 50 章 质量属性
  • 第 51 章 约束
  • 第 52 章 原则
  • 第 53 章 软件架构
  • 第 54 章 外部接口
  • 第 55 章 代码
  • 第 56 章 数据
  • 第 57 章 基础设施架构
  • 第 58 章 部署
  • 第 59 章 运营和支持
  • 第 60 章 决策日志
  • 第 61 章 问题
  • Part Ⅵ 开发生命周期中的软件架构
  • 第 62 章 敏捷和架构的冲突——神话还是现实
  • 第 63 章 量化风险
  • 第 64 章 风险风暴
  • 第 65 章 恰如其分的预先设计
  • 第 66 章 初识软件架构
  • 第 67 章 问题
  • Part Ⅶ 附录金融风险系统
  • 第 68 章 金融风险系统
  • Part Ⅷ 附录:“技术部落”的软件指南