架構(gòu)設(shè)計(jì)系列文章，請(qǐng)參見(jiàn)連接。
0. 背景
想成為架構(gòu)師或者已經(jīng)是架構(gòu)師的同學(xué)有沒(méi)有問(wèn)過(guò)自己一個(gè)問(wèn)題：為什么你是架構(gòu)師？其實(shí)就是問(wèn)問(wèn)自己為什么想成為架構(gòu)師，是不是真的是一個(gè)架構(gòu)師？架構(gòu)師只是一個(gè)稱呼，并不是你擁有了這個(gè)稱呼就是架構(gòu)師了。最主要的問(wèn)題還是架構(gòu)師和其他崗位同事的思維模式是有質(zhì)的區(qū)別的。
很多公司為了職級(jí)的完整性而定義的架構(gòu)師，技術(shù)專家到底是不是同一個(gè)概念？在某些時(shí)候授予了一些人，做了一些事可以認(rèn)為他們就是架構(gòu)師了嗎？我們這里討論和追逐的真理是你自己本身認(rèn)為你是個(gè)架構(gòu)師，而不是外部的授予。
本文主要從幾個(gè)方面為什么你是架構(gòu)師：
- 為什么你是架構(gòu)師？
主要以排除法說(shuō)明什么崗位的同事并不是架構(gòu)師。 - 架構(gòu)師的目標(biāo)與定位
架構(gòu)師以什么作為目標(biāo)和責(zé)任來(lái)幫助團(tuán)隊(duì)完成系統(tǒng)研發(fā)工作。 -
架構(gòu)師的思維方式（重點(diǎn)）
架構(gòu)師最主要的與其他人不同的點(diǎn)。 - 架構(gòu)師的執(zhí)行力（架構(gòu)師落地的過(guò)程）
架構(gòu)師要有自己的執(zhí)行能力，去具體的落地架構(gòu)設(shè)計(jì)以及解決落地過(guò)程中的問(wèn)題。 - 架構(gòu)師的溝通能力（架構(gòu)師核心的說(shuō)服力）
與團(tuán)隊(duì)，上級(jí)之間溝通推行架構(gòu)設(shè)計(jì)中的目標(biāo)。
1. 為什么你是架構(gòu)師？
架構(gòu)師不是框架師、不是算法工程師、不是高級(jí)程序員、不是項(xiàng)目經(jīng)理。架構(gòu)師與這些崗位的同事有著很多共同點(diǎn)，導(dǎo)致很多在軟件行業(yè)從業(yè)多年的人都分不清他們之間的區(qū)別。本文從不同點(diǎn)出發(fā)說(shuō)明架構(gòu)師的特點(diǎn)。
1.1 架構(gòu)師并非框架師
框架和架構(gòu)的區(qū)別大家都是知道的，可以說(shuō)框架也是有架構(gòu)的。并且框架的問(wèn)題域中有一個(gè)問(wèn)題是怎么解決業(yè)務(wù)軟件開(kāi)發(fā)過(guò)程中的架構(gòu)問(wèn)題。所以說(shuō)，框架影響著架構(gòu)但框架并不是架構(gòu)。因?yàn)榧軜?gòu)中除了框架外還有中間件、組件需要由架構(gòu)師來(lái)處理，描述框架、中間件、組件等之間的關(guān)系是架構(gòu)設(shè)計(jì)過(guò)程中技術(shù)選型內(nèi)的一部分。
對(duì)框架的架構(gòu)進(jìn)行設(shè)計(jì)與演進(jìn)也是架構(gòu)師的工作，就現(xiàn)在來(lái)說(shuō)軟件開(kāi)發(fā)基礎(chǔ)設(shè)施的開(kāi)發(fā)團(tuán)隊(duì)很少，并且軟件框架的架構(gòu)設(shè)計(jì)技術(shù)了解的人也很少。所以，可以認(rèn)為框架只不過(guò)是一種特殊的軟件，它解決的是軟件開(kāi)發(fā)與運(yùn)行階段的問(wèn)題。
可以說(shuō)對(duì)于架構(gòu)師來(lái)說(shuō)，框架只不過(guò)是一種特殊的軟件，就看要實(shí)現(xiàn)的軟件是框架、中間件、組件還是業(yè)務(wù)軟件根據(jù)軟件所處領(lǐng)域的不同進(jìn)行針對(duì)這個(gè)領(lǐng)域中的問(wèn)題進(jìn)行分析和解決即可。
1.2 架構(gòu)師并非算法工程師
隨著軟件系統(tǒng)規(guī)模的增加，計(jì)算相關(guān)的算法和數(shù)據(jù)結(jié)構(gòu)不再構(gòu)成主要的設(shè)計(jì)問(wèn)題；當(dāng)系統(tǒng)由許多部分組成時(shí)，整個(gè)系統(tǒng)的組織，也就是所說(shuō)的“軟件架構(gòu)”，導(dǎo)致了一系列新的設(shè)計(jì)問(wèn)題。
--《An Introduction to Software Architecture》卡內(nèi)基·梅隆大學(xué)的 Mary Shaw 和 David Garlan，1994 年
在我之前的文章中架構(gòu)設(shè)計(jì)00-架構(gòu)師知識(shí)體系10-對(duì)軟件認(rèn)知層次的思考中有詳細(xì)的說(shuō)明代碼是由數(shù)據(jù)結(jié)構(gòu)和算法組成的，在代碼之上還有程序、軟件、系統(tǒng)、平臺(tái)、企業(yè)架構(gòu)這幾個(gè)層次。所以，算法是組成軟件系統(tǒng)不可或缺的內(nèi)容，但算法在軟件系統(tǒng)中絕對(duì)不是主角。
根據(jù)上面mary和david所描述的由于軟件規(guī)模在不斷的擴(kuò)大，架構(gòu)更多的工作用來(lái)解決規(guī)模問(wèn)題。而不是算法和數(shù)據(jù)結(jié)構(gòu)問(wèn)題。
1.3 架構(gòu)師并非高級(jí)程序員
架構(gòu)設(shè)計(jì)的關(guān)鍵思維是判斷和取舍， 程序設(shè)計(jì)的關(guān)鍵思維是邏輯和實(shí)現(xiàn)。很多程序員在轉(zhuǎn)變?yōu)榧軜?gòu)師后，很難一開(kāi)始就意識(shí)到這個(gè)差異，還是按照寫(xiě)代碼的方式去思考架構(gòu)，這樣會(huì)導(dǎo)致很多困惑。--李運(yùn)華《從零開(kāi)始學(xué)架構(gòu)：照著做，你也能成為架構(gòu)師》
架構(gòu)設(shè)計(jì)與軟件編程一樣，有很多中模式、方法。具體使用那種模式、方法進(jìn)行實(shí)施工作并不是確定的，這樣就會(huì)有優(yōu)化的架構(gòu)和粗陋的架構(gòu)，優(yōu)秀的代碼和低劣的代碼之分。而對(duì)于架構(gòu)師來(lái)說(shuō)設(shè)計(jì)模式、架構(gòu)模式、架構(gòu)風(fēng)格在實(shí)踐中的運(yùn)用就成為了判斷架構(gòu)師能力的最基本方法。優(yōu)秀的架構(gòu)師可以讓這些有機(jī)的結(jié)合并高效的解決問(wèn)題。而高級(jí)開(kāi)發(fā)能寫(xiě)清楚設(shè)計(jì)模式已經(jīng)很不錯(cuò)了。造成這個(gè)的區(qū)別就在于決策方式與過(guò)程的不同。
1.4 架構(gòu)師并非項(xiàng)目經(jīng)理
項(xiàng)目經(jīng)理的職責(zé)是讓軟件能夠在有限的資源與時(shí)間的情況下保質(zhì)保量的交付。而架構(gòu)師為這個(gè)過(guò)程提供技術(shù)支持讓軟件能夠平順的落地。所以架構(gòu)師必須懂軟件過(guò)程過(guò)程管理，但并不是實(shí)際操作這部分內(nèi)容。
1.5 架構(gòu)師并非運(yùn)維工程師
很多架構(gòu)師都是運(yùn)維出身的，這是不爭(zhēng)的事實(shí)。不過(guò)像架構(gòu)師不是高級(jí)開(kāi)發(fā)一樣，運(yùn)維工程師成為架構(gòu)師之后也需要思維上的轉(zhuǎn)變。需要從原先的以系統(tǒng)穩(wěn)定、系統(tǒng)性能、系統(tǒng)安全而努力，轉(zhuǎn)變?yōu)檎麄€(gè)系統(tǒng)支撐、提供可行的解決方案。
2. 目標(biāo)與定位
明確了哪些不是架構(gòu)師，這里再說(shuō)明哪些是架構(gòu)師應(yīng)該持有的理念。作為架構(gòu)師實(shí)際的、落地的工作是很重要的，但應(yīng)該要想清楚在實(shí)際的設(shè)計(jì)與落地過(guò)程中我們?yōu)槭裁催@樣做。應(yīng)該抱著怎樣的理念去推進(jìn)我們的工作。
2.1 定位：業(yè)務(wù)與技術(shù)之間的橋梁
軟件架構(gòu)設(shè)計(jì)的最終目標(biāo)就是跨越業(yè)務(wù)需求與軟件實(shí)現(xiàn)之間的鴻溝，而在跨域這個(gè)鴻溝需要做的就很多。需要想盡一切辦法滿足業(yè)務(wù)與非功能需求的同時(shí)，還要讓實(shí)現(xiàn)團(tuán)隊(duì)能夠接受設(shè)計(jì)中的復(fù)雜度，以實(shí)際可行的方式設(shè)計(jì)出架構(gòu)實(shí)現(xiàn)路徑才能有益的溝通業(yè)務(wù)團(tuán)隊(duì)與技術(shù)團(tuán)隊(duì)。
2.2 目標(biāo)：
就像之前評(píng)價(jià)一個(gè)公司的層次一樣：有理想、有目標(biāo)、有原則、有方法，理解清楚通過(guò)具體化的目標(biāo)來(lái)實(shí)現(xiàn)定位中的內(nèi)容這樣層次遞進(jìn)的方式來(lái)逐步的細(xì)化來(lái)提高可行性。
通過(guò)適度設(shè)計(jì)來(lái)制定更加貼近實(shí)施過(guò)程的設(shè)計(jì)，并盡量的做到以推遲決策，快速?zèng)Q策的方式推進(jìn)實(shí)施工作。以控制復(fù)雜度來(lái)理清業(yè)務(wù)與技術(shù)的復(fù)雜度，并以合理有效的方式解決實(shí)現(xiàn)過(guò)程中的復(fù)雜度。做軟件研發(fā)只有一個(gè)目標(biāo)就是提供有價(jià)值的軟件，而有價(jià)值的軟件就必須從架構(gòu)的角度服務(wù)軟件研發(fā)過(guò)程。
-
適度設(shè)計(jì)
在馬丁富勒的《設(shè)計(jì)已死》已經(jīng)說(shuō)明了適度設(shè)計(jì)的重要性。 -
控制復(fù)雜度
在張逸老師的《解析領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》中復(fù)雜度的來(lái)源有：規(guī)模、結(jié)構(gòu)與變化。并且詳細(xì)闡述了應(yīng)對(duì)方法。 -
服務(wù)于軟件研發(fā)過(guò)程
保證架構(gòu)設(shè)計(jì)中的元素是可以被拆分與執(zhí)行的。這一原則代表著我們可以小步的交付與驗(yàn)證軟件。最主要的也是快速交付，交付有效的軟件。
2.3 達(dá)成目標(biāo)的方法
-
接受現(xiàn)實(shí)
接受自己的平凡，接受自己做的事情的平凡。我們絕大多數(shù)人都是智力平凡、能力平凡、精力平凡的人。不要認(rèn)為別人做不成的事我自己上手就絕對(duì)能做成，在平凡人做成別人做不成的事只有一個(gè)原因就是比別人更加細(xì)心更加專業(yè)才能做成他們做不成的事情。
巧婦難為無(wú)米之炊，有投入才有產(chǎn)出。只有在有實(shí)際投入的時(shí)候才能有產(chǎn)出，這句話大家都知道但是并不是所有人都能接受。需要接受它并不是相信你可以打破它。就想很多三角不可能一樣，有很多人想破解它但是從理論角度已經(jīng)證明不可能的事情是不可能破解的。
羅馬不是一天建成的，冰山之下才是關(guān)鍵。接收干起來(lái)比看起來(lái)要復(fù)雜的多也是很多人無(wú)法預(yù)先估計(jì)也無(wú)法估量的事情。但是對(duì)于我們來(lái)說(shuō)需要接受，并通過(guò)方法論來(lái)明確它即可。 -
消除不確定性
從軟件實(shí)現(xiàn)的角度來(lái)看不能有模糊的內(nèi)容，因?yàn)槟：司蜎](méi)有辦法去寫(xiě)代碼。對(duì)于架構(gòu)來(lái)說(shuō)可以模糊，因?yàn)椴淮_定的內(nèi)容可以推遲決策。所以從三個(gè)角度來(lái)消除模糊、不確定的說(shuō)法：業(yè)務(wù)需求，技術(shù)需求，管理過(guò)程。這里所有的不確定性都可以使用SMART原則來(lái)解決。 -
降低業(yè)務(wù)和系統(tǒng)的復(fù)雜度
復(fù)雜的事情對(duì)于人的認(rèn)知，解決方案的制定都是問(wèn)題。所以簡(jiǎn)化、降低復(fù)雜度是對(duì)問(wèn)題更好的應(yīng)對(duì)方式，以簡(jiǎn)化和降低復(fù)雜度為理念去實(shí)施才能真正的落地。對(duì)于這方面可以參照領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中的問(wèn)題域與解決域之間的關(guān)系。 -
為團(tuán)隊(duì)服務(wù)的理念
在管理鐵三角上只有時(shí)間和范圍的調(diào)整，沒(méi)有質(zhì)量的調(diào)整。為軟件能夠按質(zhì)按量的開(kāi)發(fā)并上線就得考慮進(jìn)入就得保證有完整的RoadMap來(lái)保證實(shí)施過(guò)程。
3. 思維方式
只有細(xì)節(jié)沒(méi)有整體，只有整體沒(méi)有細(xì)節(jié)的。并不能很好的說(shuō)明你是一個(gè)架構(gòu)師的思維方式。以《金字塔原理》的方式來(lái)系統(tǒng)的認(rèn)識(shí)一個(gè)軟件需求才能做出有效的決策。
3.1 解決問(wèn)題的方法
解決問(wèn)題必須要明確問(wèn)題，批判思維中有很多深入挖掘問(wèn)題并分析問(wèn)題的方法。在定義好問(wèn)題空間之后，對(duì)于問(wèn)題空間的解決辦法就如《恰如其分的軟件架構(gòu)》中所給出的解決方案：
-
分解
分解可以解決問(wèn)題如下：1. 有沒(méi)有應(yīng)對(duì)未知問(wèn)題的方法？2. 對(duì)于軟件系統(tǒng)的業(yè)務(wù)與技術(shù)進(jìn)行系統(tǒng)性的認(rèn)識(shí)才可以進(jìn)行決策。片面性的？ 3. 在開(kāi)發(fā)過(guò)程中與運(yùn)行過(guò)程中怎樣使用技術(shù)？ -
抽象
抽象可以解決的問(wèn)題如下：1. 對(duì)于業(yè)務(wù)的事務(wù)腳本式的寫(xiě)法來(lái)說(shuō)，怎么抽象出事務(wù)腳本中流程式的實(shí)體與關(guān)系？2. 高內(nèi)聚、低耦合在不同級(jí)別上應(yīng)該怎么實(shí)現(xiàn)？ -
知識(shí)/經(jīng)驗(yàn)
知識(shí)可以解決的問(wèn)題如下：1. 最新的就是最好的嗎？
3.3 從“問(wèn)題”開(kāi)始，而不是“技術(shù)”
技術(shù)人員對(duì)于新技術(shù)的都有著一種與身俱來(lái)的激情，總是樂(lè)于去學(xué)習(xí)新技術(shù)，同時(shí)也更有激情去使用新技術(shù)。但是這也同樣容易導(dǎo)致一個(gè)通病，就是“當(dāng)我們有一個(gè)錘子的時(shí)候看什么都是釘子”，使用一些不適合的技術(shù)去解決手邊的問(wèn)題，常常會(huì)導(dǎo)致簡(jiǎn)單問(wèn)題復(fù)雜化。
技術(shù)只是解決域中的解決工具而已，在針對(duì)不同的業(yè)務(wù)問(wèn)題選擇不同解決工具是架構(gòu)師的基本能力。很多時(shí)候這個(gè)問(wèn)題都會(huì)被導(dǎo)致，有什么樣的技術(shù)可以解決我現(xiàn)在與到的問(wèn)題，如果解決不了業(yè)務(wù)問(wèn)題就不實(shí)現(xiàn)了。這其實(shí)是一個(gè)知識(shí)陷阱，從開(kāi)發(fā)轉(zhuǎn)為架構(gòu)師時(shí)一個(gè)很重要的問(wèn)題就是超越這個(gè)問(wèn)題并解決這個(gè)問(wèn)題。
3.2 方法論
作為中層來(lái)說(shuō)并不是簡(jiǎn)單的執(zhí)行命令就可以成為一個(gè)好的架構(gòu)師，需要有自己的決策過(guò)程與決策方法。并在決策和解決問(wèn)題這兩個(gè)能力上保持有有效可實(shí)現(xiàn)的方法。
使用金字塔原理 + DDD + 分解/抽象/知識(shí)可以解決問(wèn)題，再配合例如：SMART、PDCA、SWOT、5W2H等方法來(lái)分析問(wèn)題就可以將分析到解決了。但是決策并不是一件容易的事，我在做決策是一般的流程如下：
- 系統(tǒng)性了解業(yè)務(wù)然后才能進(jìn)行決策。**
- 分析系統(tǒng)中各個(gè)點(diǎn)的重要性與優(yōu)先級(jí)。
- 根據(jù)分析結(jié)果進(jìn)行權(quán)衡過(guò)程。
- 給出解決方案并給出決策理由，并制定備用方案與決策理由。
這個(gè)過(guò)程就需要根據(jù)團(tuán)隊(duì)的情況、業(yè)務(wù)的情況、技術(shù)的情況等進(jìn)行問(wèn)題list的制定并解答。來(lái)進(jìn)行決策，問(wèn)題例如：
- 在團(tuán)隊(duì)現(xiàn)狀的情況下，怎么讓這個(gè)團(tuán)隊(duì)可以按照時(shí)間點(diǎn)實(shí)現(xiàn)出來(lái)？
- 復(fù)雜業(yè)務(wù)是不是可以進(jìn)行化簡(jiǎn)或者簡(jiǎn)約化？
- 性能問(wèn)題是否可以通過(guò)某項(xiàng)技術(shù)徹底解決，還是通過(guò)多項(xiàng)技術(shù)組合來(lái)解決？
4. 執(zhí)行力（知道怎么落地）
做了架構(gòu)設(shè)計(jì)之后要能將架構(gòu)落地，落地了才是好架構(gòu)。所以，在落地過(guò)程中需要保證實(shí)現(xiàn)的內(nèi)容是按照設(shè)計(jì)走，并且能夠很好的按照實(shí)現(xiàn)路徑進(jìn)行實(shí)現(xiàn)。在這里經(jīng)常與到的兩個(gè)問(wèn)題：
-
做正確的事，而不是容易的事。
例如：不要讓混亂的、壞味道的設(shè)計(jì)在一個(gè)組件中因?yàn)楦鞣N原因傳遞到其他組件中。 -
步子邁的太大，是不是會(huì)扯到“淡”。
計(jì)劃可以很小，落地。不能因?yàn)閴毫驮跊](méi)人，沒(méi)資源的情況下就趕著上線。
5. 溝通能力
對(duì)上要有目標(biāo)與過(guò)程，對(duì)下要有邏輯與實(shí)現(xiàn)。這樣才可以落地軟件目標(biāo)。溝通的一般原則是坦誠(chéng)，不帶任何歧視，有邏輯性，分優(yōu)先級(jí)，對(duì)事不對(duì)人。在邏輯通順，保持簡(jiǎn)單，可用很難的情況下需要說(shuō)明情況并讓團(tuán)隊(duì)達(dá)成共識(shí)。
6. 總結(jié)
君子和而不同。認(rèn)識(shí)到一件事不同的側(cè)面理解出來(lái)的內(nèi)容是不同的，但以落地實(shí)現(xiàn)就為目標(biāo)既可以達(dá)到我們最終目標(biāo)即可。所以，可以容下別人的意見(jiàn)與建議并推動(dòng)實(shí)現(xiàn)的發(fā)展才是好的實(shí)現(xiàn)。
真正優(yōu)秀的架構(gòu)都是在企業(yè)當(dāng)前人力、條件、業(yè)務(wù)等各種約束下設(shè)計(jì)出來(lái)的，能夠合理地將資源整合在一起井發(fā)揮出最大功效，井且能夠快速落地。這也是很多 BATJH (百度、阿里巴巴、騰訊、京東、華為)出來(lái)的架構(gòu)師到了小公司或創(chuàng)業(yè)團(tuán)隊(duì)反而做不出成績(jī)的原因，因?yàn)闆](méi)有了大公 司的平臺(tái)、資源、積累，只是生搬硬套大公司的做法，必然會(huì)失敗。
7. 參考：
如何從架構(gòu)圖開(kāi)始讓架構(gòu)設(shè)計(jì)平滑落地
為什么需要關(guān)注軟件架構(gòu)
上班第一周，怒懟CTO
微服務(wù)架構(gòu)及設(shè)計(jì)模式
開(kāi)發(fā)者需要知道的有關(guān)軟件架構(gòu)的五件事
你是個(gè)軟件架構(gòu)師嗎？
一位架構(gòu)師的感悟：過(guò)度忙碌使你落后
