BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Sadek Drobi 关注 0 他的粉丝 ,译者 王丽娟 关注 0 他的粉丝 发布于 2008年2月26日. 估计阅读时间: 3 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

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

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

re by michael ma

good, 很实用的好文章.

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT