【51CTO獨家特稿】“系統(tǒng)是一個個有機的生命。跟企業(yè)一樣，系統(tǒng)也需要施肥澆水，需要健康的成長。與企業(yè)一樣，一個系統(tǒng)可能會在短期內(nèi)被濫用（比如在需要短期內(nèi)快速盈利的驅(qū)使下），不過如果濫用的時間過長，系統(tǒng)最終將會無法支持。與CEO一樣，一個架構(gòu)師對系統(tǒng)的這個特性了如指掌。他們能夠識別什么是濫用，系統(tǒng)能夠承受的限度，并將系統(tǒng)引回到健康的道路上。”

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

上面是一段架構(gòu)師對于構(gòu)建優(yōu)美系統(tǒng)的描述。這段話的主人說，“架構(gòu)師是使用代碼作畫的大師。”——在他看來，架構(gòu)師最大的價值在于藝術(shù)。這并非是Fred George自家的看法，高級架構(gòu)師王翔先生也表示“好的A（編者注：A即Architect，架構(gòu)師的簡稱）需要有些藝術(shù)氣質(zhì)”。

什么是優(yōu)美的系統(tǒng)？

商業(yè)軟件項目的首要目標(biāo)是實現(xiàn)來自客戶或公司的商業(yè)需求。然而，在架構(gòu)過程中僅僅考慮到實現(xiàn)商業(yè)需求而建立的系統(tǒng)往往缺乏伸縮性、安全性、可維護性、可靠性、可移植性等等，導(dǎo)致其在短短數(shù)年內(nèi)便因無法與時俱進(jìn)而被拋棄。這一點幾乎每一位維護過項目的程序員應(yīng)該都能夠體會到：面對著缺乏文檔、不知所云的代碼，想要修改或添加一個功能卻無從下手。

而一個優(yōu)美的系統(tǒng)則是可以像有機的生命一樣成長的，這是因為從系統(tǒng)開始架構(gòu)的那一刻起，架構(gòu)師就考慮到這個系統(tǒng)以后將會面臨的挑戰(zhàn)，為系統(tǒng)的成長預(yù)留好空間。項目經(jīng)理經(jīng)常會對這位架構(gòu)師提出的看似理想化的要求不置可否——項目經(jīng)理只想著能夠盡快以比較低的成本實現(xiàn)客戶的需求，然而這些充滿藝術(shù)美感的想法其實是打造健康——因而優(yōu)美——的系統(tǒng)的根本因素。

架構(gòu)師的藝術(shù)氣質(zhì)使其站在了與項目經(jīng)理不同的立場上：項目經(jīng)理從商業(yè)需求的方向考慮，而架構(gòu)師則從系統(tǒng)本身的方向考慮。在商業(yè)氣息很濃的項目中這會引發(fā)一些沖突，這也是為什么最出色的系統(tǒng)往往出自學(xué)院，而商業(yè)項目中的架構(gòu)師必須具備權(quán)衡取舍及妥協(xié)能力的原因（參考架構(gòu)師十大技能之權(quán)衡取舍篇）。

藝術(shù)氣質(zhì)的另一體現(xiàn)就是對簡約的追求，這在Google或Apple的大部分產(chǎn)品上有很好的體現(xiàn)。看起來是兩回事，不過系統(tǒng)的簡約與系統(tǒng)的健康往往是相輔相成的。

架構(gòu)師的藝術(shù)氣質(zhì)

在軟件開發(fā)產(chǎn)業(yè)發(fā)展的過程中逐漸建立起了一些行業(yè)準(zhǔn)則和參考標(biāo)準(zhǔn)，這些將有助于架構(gòu)師在面對復(fù)雜需求時仍然能夠保持清晰地頭腦來思考問題。學(xué)習(xí)前人總結(jié)的軟件與架構(gòu)方面的知識，遵循既定的指導(dǎo)標(biāo)準(zhǔn)——比如，按照模版編寫軟件架構(gòu)文檔——看似死板，卻是必要的修煉。這些架構(gòu)師的基本功是全面的、抽象的、深層次的。沒有這些基礎(chǔ)，那么架構(gòu)師連實現(xiàn)商業(yè)需求都會感到吃力，更不要說去顧及需求之外的東西。另外我們提到過架構(gòu)師需要有前瞻性：超前的眼光是架構(gòu)師實現(xiàn)其藝術(shù)追求的彈藥。

閱讀公開的軟件架構(gòu)文檔（Software Architecture Document）是一個很好的學(xué)習(xí)途徑（在Google上能夠找到很多）。軟件架構(gòu)文檔是架構(gòu)師在項目早期階段對于系統(tǒng)的一個描述性概覽，這份文檔提供了這個系統(tǒng)預(yù)計實現(xiàn)功能的概述，這個系統(tǒng)將會使用什么技術(shù)以及可能存在的技術(shù)局限，以及最重要的部分：視圖模型。

[[7872]] 

視圖模型是業(yè)內(nèi)在20世紀(jì)90年代開始逐步建立起來的一套規(guī)范（IEEE 1471），不同的視圖從不同的角度對系統(tǒng)的不同方面進(jìn)行關(guān)注。之前所提到的項目經(jīng)理注重商業(yè)需求而架構(gòu)師注重系統(tǒng)健康的矛盾，其實在這個視圖模型中都有相應(yīng)的描述，為架構(gòu)師開展思路提供了很好的指引。過去的十多年間出現(xiàn)了很多指引性的視圖以及框架，一些常見的包括：

用例視圖（Use-Case View）：這是業(yè)務(wù)需求的角度。

邏輯視圖（Logical View）：這是功能實現(xiàn)的角度，用例執(zhí)行的流程圖。

上面兩個視圖是必需的，也往往是項目經(jīng)理最關(guān)注的部分。如果只考慮這兩個角度，系統(tǒng)可以被建立，但正如之前所描述的那樣，是不可能優(yōu)美的。架構(gòu)師還需要視情況考慮下面這些視圖：

進(jìn)程視圖（Process View）：如果系統(tǒng)是多線程的，高并發(fā)的，則需要考慮線程的角度。

部署視圖（Deployment View）：如果系統(tǒng)分布在多節(jié)點，則需要考慮服務(wù)器端和客戶端節(jié)點等硬件映射的角度。

數(shù)據(jù)視圖（Data View）：如果持久層在系統(tǒng)中很重要，則需要考慮數(shù)據(jù)的角度。

#T#還有很多其他的視圖，在這里就不一一列舉了。這些視圖都是從系統(tǒng)的角度來看問題。有些視圖框架有一定通用性，比如業(yè)內(nèi)廣為流傳的4+1模型、RM-ODP模型等等；但是對于每一個系統(tǒng)需要考慮哪些視圖，則需要架構(gòu)師去摸索、去感覺、去研究；況且現(xiàn)在新技術(shù)層出不窮，一個比較前沿的項目需要從前人沒有考慮過的角度看問題也不是沒有可能。如果架構(gòu)師沒有一定的藝術(shù)氣質(zhì)來指引方向，那么一味的照搬現(xiàn)有的模式可能會水土不服而使系統(tǒng)變得臃腫復(fù)雜，而完全不考慮商業(yè)需求之外的因素則會讓系統(tǒng)先天不足而夭折。

不過正如之前所提到的，如果沒有扎實的技術(shù)基礎(chǔ)，如果架構(gòu)師缺乏全局觀、抽象思維能力以及透過問題看本質(zhì)的能力，那么他僅僅為了實現(xiàn)客戶需求都會感到力不從心，更不用說發(fā)揮自己的藝術(shù)氣質(zhì)云云了。

從另一個角度來講，做藝術(shù)的架構(gòu)師們也都是行業(yè)里大師級別的人物了，這也是架構(gòu)師們的終極目標(biāo)吧！

本文為《架構(gòu)師害怕程序員知道的十項技能》中的藝術(shù)氣質(zhì)篇。