理想的架构并不总是和理想的技术相关

  • Sadek Drobi
  • 王丽娟

2008 年 2 月 25 日

话题:架构文化 & 方法

根据公认的定义,软件架构师的角色是定义“系统的宏观方面,这个系统则基于来自其利益相关方的投入。”这意味着架构师不能只由技术因素来驱动。他们需要记住不同利益相关方的需求,这往往制约着对技术和架构设计做出选择。

Phillip Calçado 在他的 blogpost 上强调,除了系统用户和项目赞助商之外,软件开发团队也是一个重要的利益相关方,因为开发者会直接受到架构决策的影响。因此,尽管开发环境可能会限制架构师的选择,甚至会导致放弃对项目而言客观上最好的技术,但架构师还是应该考虑开发环境

举例来说,Calçado 强调考虑团队的技术背景是极其重要的:

试想你加入一个长期从事 VB6 开发的团队去开发一个新的网站。尽管你知道 Ruby on Rails 是完成这项工作最好的工具,但是没有人有 Ruby on Rails 的相关经验。而这个网站又必须在短时间内交付,没有时间进行培训。你还会主张选择最好的技术吗?

另一个限制因素可能会来自团队的分布,无论是不是物理分布。在 Claçado 举的例子中,为证券交易所经纪人开发的系统有三个部分——数据采集、用户交互和事务,其中每一个部分由不同的团队处理。从技术上讲,即使将系统设计为单一模块可能是最好的选择,但是架构师将不得不设计三个黑盒模块,以便“团队在完全独立的组里面工作。”

总的来说,Calçado 强调道“收集那些受你的决定影响最大的小组的反馈、尊重他们的意见是很有必要的”。评论家 Alberto Brandolini 用“持续性架构(sustainable architecture)”的概念来支持同样的思路,持续性架构要求架构师保证他的“架构设计能由团队成员完成交付。”

将这种制约因素考虑在内对项目的成功是非常重要的。但是,这并不意味着因为团队在时间和技能可用度方面的约束和阻力,就一定要放弃那些真正为项目增值的技术。架构师的角色实际上是为引入变更创建策略,并将策略整合到设计当中:

[……] 架构师应该在系统的线路图中包含一个移植方案。[……] 举例来说,无论任何时候需要一段脚本或小程序,你就可以开始使用 Ruby[或任何需要的技术]、慢慢引入新的 Web 开发平台。最重要的是,你应该对系统以后应该是什么样子、以及怎么实现它有一个清楚的认识。

查看英文原文:Ideal Architecture is not always about Ideal Technology or Techniques

架构文化 & 方法