[轉(zhuǎn)載]智能＆大數(shù)據(jù)時代， 架構(gòu)師思維的十個學習步驟&演練 By 高煥堂

架構(gòu)師的第一步：學習兩種抽象視角(Abstraction View)

• 第一種抽象視角：架構(gòu)師基于<變與不變分離>的視角，尋找<萬變不離其宗>的宗，其宗(架構(gòu))的不變性帶來簡單性；讓人們能透過掌握簡單來駕馭復雜(多變)，落實了架構(gòu)師的職責。

• 第二種抽象視角：架構(gòu)師基于<形與內(nèi)涵分離>的視角，由于不同內(nèi)涵之間的<變與不變分離>已經(jīng)由第一種視角所抽象了。這個視角可從內(nèi)涵中抽像出共同之形，也可以(無中生有地)創(chuàng)造一種造形(Form)來容納內(nèi)涵(包括變與不變部分)。由于我們常常拿船運業(yè)的集裝箱(Container)來比喻<造形>；而拿形形***的貨品來比喻其(集裝箱)內(nèi)涵(Content)。所以上述的第二種視角，又稱為<集裝箱式>抽象視角。

實戰(zhàn)演練==>架構(gòu)師“集裝箱式”抽象視角

架構(gòu)師的第二步：關心下層的變動自由度(沒錢就改版，改版就有錢)

----架構(gòu)像什么? 有兩種常見的比喻。

• 架構(gòu)像房子的地基(第1種比喻)：由于地基要穩(wěn)定，上層房子才不會倒塌；因此這項比喻讓架構(gòu)師認為架構(gòu)要穩(wěn)定，上層的業(yè)務應用才會穩(wěn)定可靠。這種比喻偏于尋找不變，而不是追求創(chuàng)新。

• 架構(gòu)像一棵樹的樹干(第2種比喻)：由于樹根必須不斷成長，擁有隨環(huán)境而變動的自由度和活力；才能有效吸收更多水分和養(yǎng)分。這項比喻讓架構(gòu)師關心底層模塊(Module)的變動自由度。具有活力的樹根和樹干，才能有效之撐上層業(yè)務應用的蓬勃發(fā)展。

實戰(zhàn)演練==> 維護底層模塊的變動自由度(第2種比喻)

架構(gòu)師的第三步：<系統(tǒng)架構(gòu)控制力>支撐<商業(yè)競爭話語權(quán)>

----軟件系統(tǒng)就像一個國家的軍隊，商業(yè)模式就像一個國家的實力。

• 架構(gòu)師的職責就是要在一個系統(tǒng)架構(gòu)體系中，替自己公司的軟件系統(tǒng)(或模塊)在架構(gòu)體系中，取得制高點、取得控制力。

• 一個企業(yè)，如果在系統(tǒng)架構(gòu)體系中，處于弱勢地位的話；我們就很容易看出，它在商業(yè)競爭中，就難以取得話語權(quán)。

• 例如，曹操留給后代極高的政治智慧：挾天子以令諸侯。系統(tǒng)架構(gòu)師也能運用這項智能，來取得系統(tǒng)架構(gòu)體系中的控制力或主導權(quán)，來支撐該公司商業(yè)競爭的話語權(quán)或強龍地位。再如，Android架構(gòu)師運用HAL驅(qū)動框架，來爭取眾多硬件廠商的支持，讓Android取得系統(tǒng)控制力，支撐Google的商業(yè)強勢地位。

實戰(zhàn)演練==> 掌以握<系統(tǒng)控制點>支撐<商業(yè)話語權(quán)>

架構(gòu)師的第四步：<用戶體驗>是讓用戶享受從簡單中叫出復雜的滿足感

----架構(gòu)設計就是架構(gòu)師從復雜中找出簡單的設計過程。架構(gòu)師從復雜中得出簡單，其目的是要讓開發(fā)者(Developer)能從簡單中反過來掌握復雜；或者讓用戶(User)能從簡單中叫出復雜，并獲得其中的滿足感。茲說明如下：

• <用戶體驗是是讓用戶享受從簡單中叫出復雜的滿足感>這是蘋果公司喬幫主(Jobs)的名言。因為智能化設備的功能內(nèi)涵愈來愈復雜，如果缺乏有效的架構(gòu)師來設計出簡單，而讓用戶直接面對復雜，用戶會感到害怕；就欠缺滿足感。

• 在科學上也是如此。例如，牛頓從很復雜的力學中總結(jié)出了f=ma公式，大家就能從這簡單公式而去掌握復雜的力學了。愛因斯坦也一樣，他從復雜的規(guī)律中找出簡單的E=mc^2質(zhì)能互換公式，大家就能從這簡單公式而去了解復雜的質(zhì)能世界了。

• 為什么說它簡單呢? 理由之一是：公式的元素不超過三個，比如說，牛頓力學公式里只有F、m和a三個元素；愛因斯坦的公式也一樣，只有E、m和c三個元素。簡單的元素和公式(造形)卻蘊含極為複雜的內(nèi)涵。

• 同樣地，EIT造形的要素，也剛好就是三個。簡單的元素和造形卻蘊含極為復雜的內(nèi)涵，簡單而優(yōu)雅的接口<I>帶給開發(fā)者和用戶享受掌握復雜的滿足感。

實戰(zhàn)演練==> 從復雜設計出簡單，從簡單來掌握復雜

架構(gòu)師的第五步：創(chuàng)意愛上限制，即需求檢驗設計

----無論是移動應用、物聯(lián)網(wǎng)等都涉及愈來愈多的系統(tǒng)組合與創(chuàng)新。而軟件開發(fā)愈來愈仰賴架構(gòu)設計，所以架構(gòu)師們亟需要去學習和領悟創(chuàng)意型的架構(gòu)設計模式。這種新模式中，最傳神的隱喻是，谷歌公司副總Marissa Mayer所提倡的：

        “創(chuàng)意愛上限制"(Creativity lovesConstraint)。

她說："創(chuàng)新來自愿景與限制的互動"(Innovation is born from the interactionbetween constraint and vision)。限制迫使架構(gòu)師重新審視愿景(Vision)，從不同觀點切入，尋找新事物；同時也讓其聚精會神、厘清思路；非常具有創(chuàng)新性。這引導出架構(gòu)設計的兩個觀點：

• 觀點1：架構(gòu)來自需求。其意味著，基于需求而設計。也就是傳統(tǒng)的Rewquirement-based架構(gòu)設計。

• 觀點2：架構(gòu)基于愿景(Vision)的引導，來自架構(gòu)師的創(chuàng)意。其意味著，基于愿景而設計，需求用來檢驗架構(gòu)。一旦創(chuàng)意設計<愛上>了需求的限制，架構(gòu)(設計)自然心甘情愿地滿足需求(限制)了。

既然是觀點，本身就沒有對錯。架構(gòu)師同時擁有多個觀點，常常會帶來更多創(chuàng)意的。

實戰(zhàn)演練==> 創(chuàng)意愛上限制，需求檢驗設計

架構(gòu)師的第六步：練習假設性思維，然後”Mappingfrom vision to reality”

----愿景是對未來成功情境的想象，含有濃厚的假設性(夢想)?；诩僭O情境而設計，常常讓許多人感到不安。由于，架構(gòu)師的職責是設計一個有效架構(gòu)，既能支撐業(yè)主的愿景(Vision)，又能滿足現(xiàn)時環(huán)境(Reality)的需求限制。也就是，架構(gòu)師要找出一條從愿景映射到現(xiàn)實的一條連線(Mapping from vision to reality)，讓其它團隊成員能依循這條線而去實現(xiàn)該假設性愿境(夢想)，于是夢想成真了。在邁向智能化的大數(shù)據(jù)時代，熟練假設性思維是很關鍵的，理由是：

• 由于數(shù)據(jù)量的龐大和異型化(Different Fomat)，如迷霧一般，欲取的市場競爭優(yōu)勢，如同想從大迷宮里找到出口，最有效的途徑是：基于(假設性)想象多個最可能的出口，然后逆向推理，倒過來尋找出有效的路徑(連線)。

• 蘋果公司喬幫主(Jobs)的名言：“你不可能在眺望未來時把生活中的每個點連接起來，只有回顧時能才連點成線。”許多人并不知道，他所提的就是架構(gòu)師的關鍵任務：找到愿景(Vision)與現(xiàn)實(Reality)間的連線。這是有效架構(gòu)師必備修練。

實戰(zhàn)演練==> 練習<假設性思維>和 Mapping from vision to reality

架構(gòu)師的第七步：清晰而明確表述接口(Interface)

----基于前面第一步的兩個視角而抽象，都產(chǎn)生了<分離>的動作。分(離)是手段，而(組)合是目的。分離動作則產(chǎn)生了接口，做為后續(xù)組合的依據(jù)。分得愈美妙就能組得愈快速。分與合兩項動作，往往時間點不同，執(zhí)行者也不同；屬于跨時空、跨團隊的分工。因而，主導分(離)的架構(gòu)師，必須清晰地表述接口，并明確傳達給擔任(組)合的人員。那么，又如何清晰表述接口呢? 有效的途徑是：擅用<EIT造形(Form)>。茲說明如下：

EIT造形是由3個類(Class)所構(gòu)成的。分別以<E>、<I>和<T>來代表之。從架構(gòu)師角度上，<I>屬于主角，而<E>和<T>是配角。搭配兩個配角，才能將<I>表述的完整而清晰。就如同英語，搭配了主詞(Subject)和受詞(Object) 兩個配角，就能夠?qū)釉~(Verb)表述得更完整而清晰。例如，

• Play---沒有主詞和受詞，動詞<play>就顯得意義不夠清晰。

• 貓玩(play) 繡球---有了主詞和受詞，動詞<play>就顯得意義很清晰。

• 老師彈(play) 鋼琴---有了主詞和受詞，動詞<play>就顯得意義很清晰。

----搭配了兩個配角(主詞和受詞)，主角(動詞)的涵意就顯得更完整而清晰了。同理，架構(gòu)師只要采用EIT造形，就能將接口表述得完整而清晰了。[歡迎光臨高煥堂的博客首頁：http://www.cnblogs.com/myEIT/ ]。

實戰(zhàn)演練==> 清晰而明確表述接口(Interface)

架構(gòu)師的第八步：盡快對接口進行檢驗和測試

----基于EIT造形屬于代碼層級的造形，能迅速實現(xiàn)為軟件代碼，并進行電腦的實際執(zhí)行、檢驗和測試。軟件的編程開發(fā)是一件費時的事情，等待各層面的細節(jié)設計&代碼開發(fā)之后，才進行系統(tǒng)模塊之間的檢驗和整合測試，往往會將檢驗和測試工作時辰延后，這將大幅升高系統(tǒng)整合的風險與提高項目開發(fā)的整體成本。尤其像Android平臺的終端<軟硬整合>產(chǎn)品開發(fā)，硬件需要迅速與軟件進行整合設計(Co-Design)，才能有效降低軟硬整合的風險，縮短開發(fā)時程，并提高產(chǎn)品可靠性。擅用EIT造形，將很容易落實這個步驟的任務，如下說明：

• EIT造形的<I>是主角，架構(gòu)師必須清晰而明確定義之。至于<E>和<T>都是配角，開發(fā)者可以做<假模塊(Mock)>來實現(xiàn)<E>或<T>配角，進行對<I>的模擬測試。就如同飛機架構(gòu)師會設計<風洞>來模擬測試飛機的機翼一般。

• 目前市場上，有許多測試環(huán)境提供了Mock-based的整合測試工具，能迅速開發(fā)出 Mock<E>和Mock<T>來測試<I>，非常有助于落實這個步驟的任務了。

• 例如，想測試Client與Server模塊之間的真實接口<I>。就能設計Mock<E>與 Client銜接；并且設計Mock<T>來與Server銜接；于是既使Cleint和Server兩個模塊都還沒開發(fā)，也能迅速開發(fā)出 Mock<E>和Mock<T>來測試真實接口<I>。

實戰(zhàn)演練==> 盡快對接口進行檢驗和測試

架構(gòu)師的第九步：設計<通用性>接口，成為框架(Framework)核心要素

----架構(gòu)師如何給自己創(chuàng)造重構(gòu)的自由度，以及支持開發(fā)者重構(gòu)的空間，是框架設計的關鍵議題。這種自由度，決定于架構(gòu)師是否能仔細分辨出：關注<未來的決策>與關注<今天決策的未來性>的微妙差異了。愈是能關注<今天決策的未來性>，而不是關注<未來的決策>，就愈能創(chuàng)造未來重構(gòu)的自由度。例如，EIT造形和框架的主角都是接口<I>，愈是關注<目前決策的未來性>時，就愈會想去設計通用性(General)<E>和<I>來包容未來<T>的多變化。而一群<E&I>的巧妙組合，就成為框架了。通用性接口有兩層意義：

• 容納買主需求(或選擇)的未來變化，或容納新買主的新選擇。茲拿汽車來做比喻，當買主買了車子之后，未來隨時可以改變選擇(沙灘、公路或高山)。例如，買主未來決定將車子要到沙灘上跑時，只要更換新輪胎就行了；這展現(xiàn)出架構(gòu)師目前決策的未來性。

• 限制買主的選擇范圍。買主抉擇的改變，表現(xiàn)于應用軟件(App)上，架構(gòu)師設計通用性接口來＜框?。靖鞣NApp，限制買主的抉擇空間，才不會失控。這些通用性接口的有機整合體，就稱為軟件框架(用來框住App的架構(gòu))。

實戰(zhàn)演練==> 演練_設計通用性接口

架構(gòu)師的第十步：有效減法設計，才能開放加法(設計)

----幅員愈大的國度、大數(shù)據(jù)應用愈發(fā)達的國度，加法(設計)的幅度就愈大。加法設計幅度愈大，系統(tǒng)的復雜性和差異化就愈顯著，此時標準化和統(tǒng)一化的呼聲就愈高。無論是標準化或統(tǒng)一化，都意味著加法設計的大量推進，導致系統(tǒng)復雜而難以駕馭；因而要求架構(gòu)師提出有效的減法設計方案，從復雜中設計出簡單，讓人們能從簡單中來掌控復雜。就架構(gòu)師而言，基于有效減法的架構(gòu)設計，才能開放人人去做加法設計。茲說明如下：

• 秦朝時代唯有書同文、車同軌的有效減法設計，才能開放加法，整并六國成唯一個大國。

• 唐朝的詩叫做七言絕句，如“姑蘇城外寒山寺，夜半鐘聲到客船”，一首詩四個句子，每一個句子七個字，它的韻律有兩個“平平仄仄平平仄，仄仄平平仄仄平”，這是唐詩的主要造形(Form)。

• 秦朝的＜書同文、車同軌＞，加上唐朝的＜詩同形＞，有效的減法設計，創(chuàng)造了大一統(tǒng)(加法)的輝煌國度。

• 君不見，在前面各步驟里，諸如：從復雜中設計出簡單、以需求檢驗設計等都是基于有效的減法設計，一方面給設備供貨商一個開放的加法設計空間；另一方面則讓用戶享受從簡單(來自減法設計)中叫出復雜的滿足感。

• 此外，在前面各步驟里，諸如：EIT造形、通用性接口和軟件框架(框住某些東西)等，則是減法設計的實踐技術(shù)；基于這些有效的減法設計途徑，才能大幅開放加法設計；因而落實了：從簡單中掌握復雜。[歡迎光臨高煥堂的博客首頁：http://www.cnblogs.com/myEIT/ ]。

實戰(zhàn)演練==> 有效減法設計，才能開放加法