【51CTO獨家特稿】在訪問聚聚呀項目總監(jiān)梁遠華先生時，梁先生說到“權(quán)衡取舍”是一個架構(gòu)師在項目中最難把握的。“一個產(chǎn)品會有很多的東西要做，什么是可做的，什么是重要的，什么是將來能做的，每天都做做選擇題。”

51CTO開發(fā)頻道年終巨獻:架構(gòu)師最怕程序員知道的十件事

eBay的杰出架構(gòu)師Randy Shoup先生也表示“對權(quán)衡取舍方面有著出色的把控能力”是自己團隊招聘架構(gòu)師的一個重要要求。

你聽說過軟件架構(gòu)師的職業(yè)培訓(xùn)中有一個叫做ATAM的課程么？ATAM，全稱Architecture Tradeoff Analysis Method，意為架構(gòu)權(quán)衡分析方法。雖然這樣的培訓(xùn)并非必要，但是值得我們?nèi)W習了解一下。

 
ATAM概念流程圖

沒有一個人可以建造一個沒有缺陷的架構(gòu)。這個項目可能缺乏時間，缺乏金錢，缺乏人手，或者缺乏合適的技術(shù)。在項目從開始到進行中的每時每刻，架構(gòu)師都需要對這些架構(gòu)的“缺陷”有明確的了解。

在架構(gòu)師的藝術(shù)氣質(zhì)篇我們提到了“基于需求考慮問題”和“基于系統(tǒng)考慮問題”的不同，并提到這中間會存在一些矛盾，需要架構(gòu)師來做權(quán)衡決策。站在系統(tǒng)的角度上，架構(gòu)師可能覺得自己手頭的資源不夠，他需要更多的時間、人以及新技術(shù)，但是項目經(jīng)理和其他團隊成員很可能會拒絕，而他們也有自己的理由。

所以Fred George先生提出了“短期濫用”的說法，即在系統(tǒng)能夠承受的范圍內(nèi)做出一些妥協(xié)。在ATAM方法中，分析的思路是基于“情景”的：你需要提出各種可能的情景，然后來證明在每一個用戶使用場景中，系統(tǒng)的哪一些內(nèi)容是必要的、不可丟棄的——從而確定哪些部分是暫時可以不予考慮的。

到了這一步，便已經(jīng)是一個技術(shù)性問題；但是這個問題的解決過程卻是對架構(gòu)師“軟”技能的一個考驗：即架構(gòu)師有沒有看到各方面訴求的差異，以及有沒有意愿為了這些差異而做出妥協(xié)。

案例分析1

讓我們看一個案例，這是現(xiàn)任微軟Visual Studio Business Applications總經(jīng)理潘正磊女士在博客上分享的一段經(jīng)歷：

“分享一件去年發(fā)生在上海Visual Studio團隊和印度SQL Server團隊之間的故事。兩個團隊郵件往來10個回合后仍無法在某個問題上達成一致，因此上海團隊把我拉進了郵件討論。于是我從頭開始讀郵件，讀到第四封我大致了解到，分歧的根源在于，兩個團隊所溝通的，根本不是同一件事。

印度團隊認為自己開發(fā)了一個特別棒的SQL Compact工具，能滿足客戶的重要需求，所以要求把這個功能加入Visual Studio 2010 Beta 1 (Visual Studio 2010 的第一個公開測試版)；上海團隊認為當時已接近測試版的發(fā)布日期，考慮到功能加入產(chǎn)品前必須遵循的一系列發(fā)布流程，時間上恐怕來不及了。之后的郵件里，印度團隊一直強調(diào)這個功能是多么棒，應(yīng)該讓它在測試版中發(fā)布（也就是一個解決方案），卻從沒有解釋他們要解決什么問題；上海團隊則不斷重申功能加入必須按流程來，可見他們之間的交流完全錯位了。在這個典型的案例中，印度團隊努力推動一個解決方案，卻沒有想清楚所要解決的問題為什么會對上海團隊也非常重要。之后，我們發(fā)現(xiàn)的確有一個用戶使用場景需要用到SQL Compact工具，于是我們詢問新工具對這個使用場景有何幫助，是否能與其他新功能兼容 … …一旦我們能明確這個問題的本質(zhì)，我們就不難找出雙方都接受的解決方案，例如，立即加入第一個測試版，或稍后加入第二個測試版，甚至是加入Service Pack等等。”

如果說架構(gòu)師的藝術(shù)氣質(zhì)體現(xiàn)在其把系統(tǒng)當做生命、站在系統(tǒng)本身的角度思考問題，那么架構(gòu)師出于對客戶、項目經(jīng)理、開發(fā)者和測試者不同視角的理解而做出權(quán)衡妥協(xié)則充分體現(xiàn)了其職業(yè)性。上面潘女士提到的案例，是一個大型項目中的兩個開發(fā)團隊之間的理解沖突所引起的。

A：一個特別棒的功能應(yīng)該被加入到產(chǎn)品發(fā)布中。

B：一個功能加入到產(chǎn)品發(fā)布中應(yīng)該要謹慎并經(jīng)過充分的審核。

這是“把一個功能加入到產(chǎn)品發(fā)布”從兩個角度的解讀，兩個解讀都有自己的道理。而在潘女士參與之前，雙方的論點沒有交集，“交流錯位”了。而要實現(xiàn)權(quán)衡與妥協(xié)的前提，則是讓B了解“這個功能是很棒”，并且讓A了解“新功能必須在謹慎考量之后才能加入產(chǎn)品發(fā)布”。在潘女士的努力下，雙方最后都理解了對方，并找到了都能接受的解決方案。而這個過程正是通過設(shè)計和描述“場景(scenario)”來推動的。

案例分析2

上面是開發(fā)工具項目中的一個小案例，下面讓我們看看另一個案例。Amazon.com的CTO，Werner Vogels在08年的12月底發(fā)過一篇很有參考價值的博文：Eventually Consistent（最終一致），討論對象是Amazon的S3，SimpleDB，EC2等大型云計算服務(wù)。Werner對這些服務(wù)的描述直達本質(zhì)，一針見血：“這些服務(wù)需要在安全、伸縮性、可用性、性能以及性價比方面獲得高分，同時必須維持全球上百位客戶不間斷的使用需求。”

文中講述了不少深入的架構(gòu)知識，對于廣大程序員而言或許有些難以理解；但是有一句話是一句很直白的經(jīng)驗總結(jié)，充分的解釋了“權(quán)衡妥協(xié)”的意思：“在一個理想的世界中，只存在唯一一個一致模型：在實施一次升級之后，所有觀察者都能夠看到這個升級。”言外之意就是，對于系統(tǒng)而言，在某一個地方或某一個層面發(fā)生的改變，勢必將影響到系統(tǒng)的其他地方和層面，乃至整個系統(tǒng)。正因為系統(tǒng)的各個部分是互相關(guān)聯(lián)的，因此為每一個變動考慮權(quán)衡（trade-off）是必要的，有意義的。

Werner提到的一個正面案例就是在90年代中期的時候，人們只知道可用性(availability)很重要，但對于追求可用性需要犧牲什么渾然不知。出于對可用性權(quán)衡的研究，加州大學的Eric Brewer教授提出了CAP理論，認為對于一個共享數(shù)據(jù)的系統(tǒng)而言，數(shù)據(jù)持續(xù)性、系統(tǒng)可用性、對網(wǎng)絡(luò)劃分的耐受性這三個屬性（property）是不可調(diào)和的，任何時候只能同時達成兩個。

雖然理論只是理論，但理論并非憑空而來，Eric的理論是總結(jié)了90年代大型互聯(lián)網(wǎng)系統(tǒng)建設(shè)的經(jīng)驗研究成果。對于Amazon云計算服務(wù)的架構(gòu)師而言，這些經(jīng)驗總結(jié)自然是無法忽視的；在知道了魚和熊掌不可兼得的情況下，要深刻理解各個方面不同角度的訴求，并找出各方都可以接受妥協(xié)的制衡點，自然是必不可少的。

總結(jié)

#T#具體要如何制衡是一個很大的話題，甚至于每個系統(tǒng)都會有不同的情況。很多人在各個方面都做過很多研究，指導(dǎo)架構(gòu)師們一些方向。對于架構(gòu)師而言，僅僅有權(quán)衡妥協(xié)的意識還遠遠不夠：這個意識只是前提之一，如果缺乏了對技術(shù)扎實的了解，那么這個意識則毫無意義。同時在分析權(quán)衡的過程中會有很多抽象的概念（這些概念可能還需要被量化），并且深入到系統(tǒng)的各個層面，因此架構(gòu)師的抽象思維能力和看到問題本質(zhì)的素質(zhì)也是必須的。

抽象能力，深入本質(zhì)，權(quán)衡意識——這三點都是十分珍貴的思想素質(zhì)。這三種能力配合豐富而扎實的“硬”技能（技術(shù)）、合格的“軟”技能（溝通）以及敏銳的眼光，無論在哪個行業(yè)都能成功。而由于架構(gòu)師這個職業(yè)本身就是IT界的高級職業(yè)，這所有的能力和素質(zhì)就都成了架構(gòu)師的入門必備敲門磚。不過每個人的時間、精力以及天生素質(zhì)都是不同的，本次介紹的架構(gòu)師十大技能全部修煉是很困難的。想要成為架構(gòu)師的程序員們，首先要自己權(quán)衡決策一下，看看自己應(yīng)該如何修煉才能達到最好的效果——這也是權(quán)衡能力的一次練習吧。

本文為《架構(gòu)師害怕程序員知道的十項技能》中的權(quán)衡取舍篇。