【51CTO独家特稿】在访问聚聚呀项目总监梁远华先生时，梁先生说到“权衡取舍”是一个架构师在项目中最难把握的。“一个产品会有很多的东西要做，什么是可做的，什么是重要的，什么是将来能做的，每天都做做选择题。”
eBay的杰出架构师Randy Shoup先生也表示“对权衡取舍方面有着出色的把控能力”是自己团队招聘架构师的一个重要要求。
你听说过软件架构师的职业培训中有一个叫做ATAM的课程么？ATAM，全称Architecture Tradeoff Analysis Method，意为架构权衡分析方法。虽然这样的培训并非必要，但是值得我们去学习了解一下。
ATAM概念流程图
没有一个人可以建造一个没有缺陷的架构。这个项目可能缺乏时间，缺乏金钱，缺乏人手，或者缺乏合适的技术。在项目从开始到进行中的每时每刻，架构师都需要对这些架构的“缺陷”有明确的了解。
在架构师的艺术气质篇我们提到了“基于需求考虑问题”和“基于系统考虑问题”的不同，并提到这中间会存在一些矛盾，需要架构师来做权衡决策。站在系统的角度上，架构师可能觉得自己手头的资源不够，他需要更多的时间、人以及新技术，但是项目经理和其他团队成员很可能会拒绝，而他们也有自己的理由。
所以Fred George先生提出了“短期滥用”的说法，即在系统能够承受的范围内做出一些妥协。在ATAM方法中，分析的思路是基于“情景”的：你需要提出各种可能的情景，然后来证明在每一个用户使用场景中，系统的哪一些内容是必要的、不可丢弃的——从而确定哪些部分是暂时可以不予考虑的。
到了这一步，便已经是一个技术性问题；但是这个问题的解决过程却是对架构师“软”技能的一个考验：即架构师有没有看到各方面诉求的差异，以及有没有意愿为了这些差异而做出妥协。
案例分析1
让我们看一个案例，这是现任微软Visual Studio Business Applications总经理潘正磊女士在博客上分享的一段经历：
“分享一件去年发生在上海Visual Studio团队和印度SQL Server团队之间的故事。两个团队邮件往来10个回合后仍无法在某个问题上达成一致，因此上海团队把我拉进了邮件讨论。于是我从头开始读邮件，读到第四封我大致了解到，分歧的根源在于，两个团队所沟通的，根本不是同一件事。
印度团队认为自己开发了一个特别棒的SQL Compact工具，能满足客户的重要需求，所以要求把这个功能加入Visual Studio 2010 Beta 1 (Visual Studio 2010 的第一个公开测试版)；上海团队认为当时已接近测试版的发布日期，考虑到功能加入产品前必须遵循的一系列发布流程，时间上恐怕来不及了。之后的邮件里，印度团队一直强调这个功能是多么棒，应该让它在测试版中发布（也就是一个解决方案），却从没有解释他们要解决什么问题；上海团队则不断重申功能加入必须按流程来，可见他们之间的交流完全错位了。在这个典型的案例中，印度团队努力推动一个解决方案，却没有想清楚所要解决的问题为什么会对上海团队也非常重要。之后，我们发现的确有一个用户使用场景需要用到SQL Compact工具，于是我们询问新工具对这个使用场景有何帮助，是否能与其他新功能兼容 … …一旦我们能明确这个问题的本质，我们就不难找出双方都接受的解决方案，例如，立即加入第一个测试版，或稍后加入第二个测试版，甚至是加入Service Pack等等。”
如果说架构师的艺术气质体现在其把系统当做生命、站在系统本身的角度思考问题，那么架构师出于对客户、项目经理、开发者和测试者不同视角的理解而做出权衡妥协则充分体现了其职业性。上面潘女士提到的案例，是一个大型项目中的两个开发团队之间的理解冲突所引起的。
A：一个特别棒的功能应该被加入到产品发布中。
B：一个功能加入到产品发布中应该要谨慎并经过充分的审核。
这是“把一个功能加入到产品发布”从两个角度的解读，两个解读都有自己的道理。而在潘女士参与之前，双方的论点没有交集，“交流错位”了。而要实现权衡与妥协的前提，则是让B了解“这个功能是很棒”，并且让A了解“新功能必须在谨慎考量之后才能加入产品发布”。在潘女士的努力下，双方最后都理解了对方，并找到了都能接受的解决方案。而这个过程正是通过设计和描述“场景(scenario)”来推动的。
案例分析2
上面是开发工具项目中的一个小案例，下面让我们看看另一个案例。Amazon.com的CTO，Werner Vogels在08年的12月底发过一篇很有参考价值的博文：Eventually Consistent（最终一致），讨论对象是Amazon的S3，SimpleDB，EC2等大型云计算服务。Werner对这些服务的描述直达本质，一针见血：“这些服务需要在安全、伸缩性、可用性、性能以及性价比方面获得高分，同时必须维持全球上百位客户不间断的使用需求。”
文中讲述了不少深入的架构知识，对于广大程序员而言或许有些难以理解；但是有一句话是一句很直白的经验总结，充分的解释了“权衡妥协”的意思：“在一个理想的世界中，只存在唯一一个一致模型：在实施一次升级之后，所有观察者都能够看到这个升级。”言外之意就是，对于系统而言，在某一个地方或某一个层面发生的改变，势必将影响到系统的其他地方和层面，乃至整个系统。正因为系统的各个部分是互相关联的，因此为每一个变动考虑权衡（trade-off）是必要的，有意义的。
Werner提到的一个正面案例就是在90年代中期的时候，人们只知道可用性(availability)很重要，但对于追求可用性需要牺牲什么浑然不知。出于对可用性权衡的研究，加州大学的Eric Brewer教授提出了CAP理论，认为对于一个共享数据的系统而言，数据持续性、系统可用性、对网络划分的耐受性这三个属性（property）是不可调和的，任何时候只能同时达成两个。
虽然理论只是理论，但理论并非凭空而来，Eric的理论是总结了90年代大型互联网系统建设的经验研究成果。对于Amazon云计算服务的架构师而言，这些经验总结自然是无法忽视的；在知道了鱼和熊掌不可兼得的情况下，要深刻理解各个方面不同角度的诉求，并找出各方都可以接受妥协的制衡点，自然是必不可少的。
总结
#T#具体要如何制衡是一个很大的话题，甚至于每个系统都会有不同的情况。很多人在各个方面都做过很多研究，指导架构师们一些方向。对于架构师而言，仅仅有权衡妥协的意识还远远不够：这个意识只是前提之一，如果缺乏了对技术扎实的了解，那么这个意识则毫无意义。同时在分析权衡的过程中会有很多抽象的概念（这些概念可能还需要被量化），并且深入到系统的各个层面，因此架构师的抽象思维能力和看到问题本质的素质也是必须的。
抽象能力，深入本质，权衡意识——这三点都是十分珍贵的思想素质。这三种能力配合丰富而扎实的“硬”技能（技术）、合格的“软”技能（沟通）以及敏锐的眼光，无论在哪个行业都能成功。而由于架构师这个职业本身就是IT界的高级职业，这所有的能力和素质就都成了架构师的入门必备敲门砖。不过每个人的时间、精力以及天生素质都是不同的，本次介绍的架构师十大技能全部修炼是很困难的。想要成为架构师的程序员们，首先要自己权衡决策一下，看看自己应该如何修炼才能达到最好的效果——这也是权衡能力的一次练习吧。
本文为《架构师害怕程序员知道的十项技能》中的权衡取舍篇。
