确定对架构的关键需求.docVIP

. .. . .可修编. 关键需求决定架构。 软件架构师没有时间对“所有需求〞进展深入分析，这是现实——大多数工程都面临工程工期的压力，软件架构师必须在一定的时间定夺架构设计方案；否那么，没有软件架构所提供的对技术的足够指导以及对分工协作的足够限制，后期的团队开发将面临巨大风险。 软件架构师没有必要对“所有需求〞进展深入分析，这是策略——把大局部时间和精力花在对决定架构最重要的一局部需求上，好钢用在刀刃上，最终你设计出的软件架构的质量反而会更高；否那么，所有需求的分析都不够深入，导致最终设计出的软件架构可能会流于形式。 6.1? 虚拟顶峰论坛：穷兵黩武还是择战而斗 解释一下这两个隐喻。所谓“穷兵黩武〞是指把所有需求彻底分析一遍从而设计出软件架构的做法，而“择战而斗〞是指为了设计架构仅重点分析对软件架构起关键作用的一局部需求的做法。 读书犹如和作者交谈。本节的写作形式颇为轻松：我们假设把一些高人请到了一起，就“从软件需求到软件架构〞问题展开一个“顶峰论坛〞〔当然是虚拟的〕。 6.1.1? 需任何促成设计决策的因素 说到底，一个软件系统的软件架构最终设计成什么样，是由软件需求决定的。 咨询专家Brian Lawrence提出：“需任何促成设计决策的因素〔Anything that drives design choices〕。〞 6.1.2? 很少有开发者能奢侈地拥有一个稳定的需求集 “需求决定架构〞。话虽这么说，但现实要复杂得多，因为软件需求本身会因需求背景的变化和工程人员的理解等问题发生变更。 正如?软件需求管理：统一方法?的作者Dean Leffingwell所说：“很少有开发者能奢侈地拥有一个稳定的需求集……〞 6.1.3? 关键性的第一步是缩小围 勿在浮沙筑高台。倘假设作为架构设计重要依据的软件需求变化了，你建起的软件架构这个“高台〞岂不是要倒塌？ 杰拉尔德·温伯格的话让人更深刻地体会到了“运筹帷幄〞应有的含义，他说：“关键性的第一步是缩小围……〞 6.1.4? 要择战而斗 穷兵黩武还是择战而斗，这或许不是问题，因为我们已经倾向于择战而斗了。但问题在于，择战而斗怎么个“择〞法。 PeopleSoft公司的首席技术官Rick Bergquist说得精辟：“我的第一个老板John Grillos曾说过，要择战而斗。择战的标准如下：它们要具有重要性，它们要具有可能性，它们的数量要少。〞 6.1.5? 功能、质量和商业需求的某个集合塑造了构架 方向已经明确了，不是吗？软件架构师要着重深入分析的是软件需求的一个子集，再结合自己的经历，最终设计出软件架构。 卡基梅隆大学软件工程研究所的Len Bass指出：“功能、质量和商业需求的某个集合‘塑造’了构架。我们把这些塑造需求称为‘构架驱动因素’。……知道了构架驱动因素后，就可以开场构架设计了。〞 6.2? 关键需求决定架构 6.2.1? 实践中的常见问题 在从需求工作向架构设计工作转移的环节上，我们在实践中暴露出一些问题。对于软件架构师而言，这些问题在一定程度上相当普遍，所以我们一起来解决它们。 问题一：抱怨留给架构设计的时间太短，而不是承受工程节奏普遍加快的现实。 从根本上讲，这是没有意识到软件开发所根植于的业务背景——当然，我相信或多或少也受到瀑布模型的影响。无论是对于企业业务还是个人业务，在复杂和高速变化的经济环境里，在对手云集的竞争条件下，软件系统“上马〞太慢本身就潜藏着巨大风险。在?非程序员?第50期中有一篇来自Markus V?lter和JornBettin的论文?模型驱动软件开发模式?，其中强调新的商业应用的开发期最多不得超过9个月： …… 每三个月至少要提供可交付代码。 理想情况下，每三个月应将代码部署到产品中，并得到实际反应。 新的商业应用的开发，必须在九个月之“哇哇坠地〞，否那么就可能危及“妈妈〞〔开发组〕或“婴儿〞〔应用〕的生命…… 问题二：认为必须详细分析所有的需求，只有这样才能设计出满足所有需求的软件架构 有仗就打、有人讨敌骂阵就出战，这种情形在历史小说里经常见到，但往往出现在有勇无谋的武将身上。与此类似，想要将所面对的所有需求都分析一遍的软件架构师是否想过：这是否现实？在有限的时间里，将精力分散在过多的问题上，其结果往往是效果更差。 我们的策略是：关键需求决定架构，其余需求验证架构。 顺着“全面认识需求〞的策略思考开去，很容易让人产生疑问：你是在说瀑布式开发吗？当然不是。我们的策略是：在架构设计期间，关键需求决定架构，其余需求验证架构。也就是说，“关键需求决定架构〞和“