程序員必讀之軟件架構(gòu)（中文版）

峭據(jù)辭￥

目錄

第1章什么是架構(gòu)

作為名詞

作為動(dòng)詞

第2章架構(gòu)的種類

它們的共同點(diǎn)是什么

第3章軟件架構(gòu)是什么

應(yīng)用程序架構(gòu)

系統(tǒng)架構(gòu)

軟件架構(gòu)

企業(yè)架構(gòu)：戰(zhàn)略而非代碼

第4章敏捷軟件架構(gòu)是什么

理解“敏捷”

好的架構(gòu)帶來(lái)敏捷

你需要有多敏捷

第5章架構(gòu)對(duì)上設(shè)計(jì)

找出區(qū)別

理解意義

第6章軟件架構(gòu)重要嗎

缺乏軟件架構(gòu)將引發(fā)問(wèn)題

軟件架構(gòu)的好處

所有軟件項(xiàng)目都需要軟件架構(gòu)嗎

第7章問(wèn)題

PartII軟件架構(gòu)的角色

第8章軟件架構(gòu)的角色

1.架構(gòu)驅(qū)動(dòng)力

2.設(shè)計(jì)軟件

3.技術(shù)風(fēng)險(xiǎn)

4.架構(gòu)演化

5.編寫代碼

6.質(zhì)量保證

合作或失敗

技術(shù)領(lǐng)導(dǎo)是一個(gè)角色而非級(jí)別

提出你自己對(duì)這個(gè)角色的定義

第9章軟件架構(gòu)師應(yīng)該編碼嗎

編寫代碼

構(gòu)建原型、框架和基礎(chǔ)

進(jìn)行代碼評(píng)審

實(shí)驗(yàn)并與時(shí)俱進(jìn)

軟件架構(gòu)師和雇主之間的矛盾

你不必放棄編碼

不要把全部時(shí)間都用于編碼

第10章軟件架構(gòu)師應(yīng)該是建造大師

聯(lián)盟的狀態(tài)

回顧過(guò)去

建造大師真的會(huì)建造嗎

象牙塔

建造大師角色的差異

實(shí)現(xiàn)角色

架構(gòu)師要和團(tuán)隊(duì)一起工作

第11章從開發(fā)者到架構(gòu)師

經(jīng)驗(yàn)是一個(gè)好的評(píng)價(jià)標(biāo)準(zhǔn)，但你需要看得更深

模糊的界線

跨越界線是我們的責(zé)任

第12章拓展T

進(jìn)一步的技術(shù)能力

知識(shí)面寬

軟件架構(gòu)師是通才型專家

軟件架構(gòu)是技術(shù)活

第13章軟技能

保持積極

第14章軟件架構(gòu)不是接力運(yùn)動(dòng)

解決方案架構(gòu)師

要有人負(fù)責(zé)大局

第15章軟件架構(gòu)要引入控制嗎

提供指導(dǎo)，追求一致性

控制的程度

控制因文化而不同

操縱桿，而非按鈕

第16章小心鴻溝

開發(fā)者關(guān)注底層細(xì)節(jié)

閉門造車的獨(dú)裁架構(gòu)師

拉近距離

如果你是軟件架構(gòu)師

如果你是軟件開發(fā)者

軟件架構(gòu)的合作方式

第17章未來(lái)的軟件架構(gòu)師在哪里

指導(dǎo)、輔導(dǎo)和師徒關(guān)系

我們正在失去技術(shù)導(dǎo)師

軟件團(tuán)隊(duì)需要休息

第18章每個(gè)人都是架構(gòu)師，除非他們有其他身份

每個(gè)人都是架構(gòu)師

除非他們有其他身份

敏捷需要架構(gòu)嗎

第19章軟件架構(gòu)咨詢師

領(lǐng)域知識(shí)

權(quán)威

第20章問(wèn)題

PartIII設(shè)計(jì)軟件

第21章架構(gòu)驅(qū)動(dòng)力

功能需求

質(zhì)量屬性

約束

原則

理解影響

第22章質(zhì)量屬性（非功能需求）

哪些對(duì)你重要

第23章處理非功能需求

捕捉

提煉

挑戰(zhàn)

第24章約束

時(shí)間和預(yù)算的約束

技術(shù)約束

人員約束

組織約束

約束都是不好的嗎

約束可以劃分優(yōu)先級(jí)

傾聽約束

第25章原則

開發(fā)原則

架構(gòu)原則

謹(jǐn)防最佳實(shí)踐

第26章技術(shù)不是實(shí)現(xiàn)細(xì)節(jié)

你有復(fù)雜的非功能需求嗎

你有約束嗎

你有一致性嗎

推遲與解耦

每個(gè)決策都是權(quán)衡

第27章更多分層等于更高復(fù)雜度

非功能需求

時(shí)間和預(yù)算：沒(méi)有什么是免費(fèi)的

第28章協(xié)同設(shè)計(jì)是一把雙刃劍

經(jīng)驗(yàn)影響軟件設(shè)計(jì)

第29章軟件架構(gòu)是對(duì)話的平臺(tái)

軟件開發(fā)不只是交付特性

第30章SharePoint項(xiàng)目也需要軟件架構(gòu)

很多SharePoint實(shí)現(xiàn)都不只是SharePoint

非功能性需求仍然適用于SharePoint解決方案

SharePoint項(xiàng)目很復(fù)雜，也需要技術(shù)領(lǐng)導(dǎo)力

SharePoint解決方案仍然需要編寫文檔

強(qiáng)大的領(lǐng)導(dǎo)力和紀(jì)律不只是針對(duì)軟件開發(fā)項(xiàng)目

第31章問(wèn)題

PartIV可視化軟件

第32章溝通障礙

拋棄UML

敏捷需要良好的溝通

第33章對(duì)草圖的需要

測(cè)試驅(qū)動(dòng)開發(fā)與圖表

為什么人們應(yīng)該學(xué)習(xí)如何畫草圖

畫草圖不是藝術(shù)

畫草圖不是綜合模型

畫草圖可以是協(xié)作活動(dòng)

第34章無(wú)效的草圖

采購(gòu)清單

只有框沒(méi)有線

“功能視圖”

航線圖

一般正確

推遲技術(shù)

部署和執(zhí)行上下文

太多假設(shè)

無(wú)家可歸的C#對(duì)象（HOCO）

選擇你自己的冒險(xiǎn)

應(yīng)該用白板

創(chuàng)建有效的草圖

第35章C4：語(yǔ)境、容器、組件和類

通用的抽象集合

總結(jié)軟件的靜態(tài)視圖

通用標(biāo)記法的通用抽象

圖應(yīng)該簡(jiǎn)單且腳踏實(shí)地

第36章語(yǔ)境圖

意圖

結(jié)構(gòu)

用戶、演員、角色、人物等

IT系統(tǒng)

交互

動(dòng)機(jī)

受眾

示例

第37章容器圖

意圖

結(jié)構(gòu)

容器

交互

系統(tǒng)邊界

動(dòng)機(jī)

受眾

示例

第38章組件圖

意圖

結(jié)構(gòu)

組件

交互

動(dòng)機(jī)

受眾

示例

第39章是否包含技術(shù)選擇

在設(shè)計(jì)過(guò)程中繪圖

回顧性繪圖

架構(gòu)圖應(yīng)該概念化

明確技術(shù)選擇

第40章你會(huì)那樣編碼嗎

共享組件

分層策略

圖應(yīng)該反映現(xiàn)實(shí)

第41章軟件架構(gòu)和編碼

職責(zé)驅(qū)動(dòng)設(shè)計(jì)和組件分解

我們談?wù)摻M件但編寫類

用層封裝代碼

用特性封裝

用組件封裝

對(duì)齊軟件架構(gòu)和代碼

第42章你不需要UML工具

有很多類型的UML工具

既有效又簡(jiǎn)單

UML的用途

沒(méi)有銀彈

第43章有效的草圖

標(biāo)題

標(biāo)簽

形狀

職責(zé)

線條

顏色

邊框

布局

方向

要點(diǎn)

圖表的評(píng)審清單

傾聽問(wèn)題

第44章C4的常見(jiàn)問(wèn)題

語(yǔ)境圖上的系統(tǒng)名稱

混合的抽象層次

共享組件

工具組件

從IT的角度勾畫企業(yè)語(yǔ)境

第45章問(wèn)題

PartV為軟件生成文檔

第46章代碼不會(huì)講述完整的故事

代碼未描繪的設(shè)計(jì)意圖

輔助信息

第47章軟件文檔即指南

1.地圖

2.景色

3.歷史和文化

4.實(shí)用信息

保持短小簡(jiǎn)潔

注意“視圖”

產(chǎn)品與項(xiàng)目文檔

第48章語(yǔ)境

意圖

結(jié)構(gòu)

動(dòng)機(jī)

受眾

是否必須

第49章功能性概覽

意圖

結(jié)構(gòu)

動(dòng)機(jī)

受眾

是否必須

第50章質(zhì)量屬性

意圖

結(jié)構(gòu)

動(dòng)機(jī)

受眾

是否必須

第51章約束

意圖

結(jié)構(gòu)

動(dòng)機(jī)

受眾

是否必須

第52章原則

意圖

結(jié)構(gòu)

動(dòng)機(jī)

受眾

是否必須

第53章軟件架構(gòu)

意圖

結(jié)構(gòu)

動(dòng)機(jī)

受眾

是否必須

第54章外部接口

意圖

結(jié)構(gòu)

動(dòng)機(jī)

受眾

是否必須

第55章代碼

意圖

結(jié)構(gòu)

動(dòng)機(jī)

受眾

是否必須

第56章數(shù)據(jù)

意圖

結(jié)構(gòu)

56.3動(dòng)機(jī)

受眾

是否必須

第57章基礎(chǔ)設(shè)施架構(gòu)

意圖

結(jié)構(gòu)

動(dòng)機(jī)

受眾

是否必須

第58章部署

意圖

結(jié)構(gòu)

動(dòng)機(jī)

受眾

是否必須

第59章運(yùn)營(yíng)和支持

意圖

結(jié)構(gòu)

動(dòng)機(jī)

受眾

是否必須

第60章決策口志

意圖

結(jié)構(gòu)

動(dòng)機(jī)

受眾

是否必須

第61章問(wèn)題

PartVI開發(fā)生命周期中的軟件架構(gòu)

第62章敏捷和架構(gòu)的沖突：神話還是現(xiàn)實(shí)

沖突1：團(tuán)隊(duì)結(jié)構(gòu)

沖突2：流程和產(chǎn)出

軟件架構(gòu)提供了TDD、BDD、DDD、RDD和代碼整潔的分界線

從象牙塔和大型預(yù)先設(shè)計(jì)中分離出架構(gòu)

第63章量化風(fēng)險(xiǎn)

概率與影響

設(shè)定風(fēng)險(xiǎn)的優(yōu)先級(jí)

第64章風(fēng)險(xiǎn)風(fēng)暴

步驟1:畫一些架構(gòu)圖

步驟2：分別識(shí)別風(fēng)險(xiǎn)

步驟3：匯總圖中的風(fēng)險(xiǎn)

步驟4：對(duì)風(fēng)險(xiǎn)設(shè)定優(yōu)先級(jí)

緩解策略

何時(shí)使用風(fēng)險(xiǎn)風(fēng)暴

集體所有制

第65章恰如其分的預(yù)先設(shè)計(jì)

回到方法學(xué)

要做到“恰如其分”

多少預(yù)先設(shè)計(jì)是太少

多少預(yù)先設(shè)計(jì)是太多

多少是“恰如其分”

把恰如其分的預(yù)先設(shè)計(jì)置于適當(dāng)?shù)恼Z(yǔ)境

第66章初識(shí)軟件架構(gòu)

軟件架構(gòu)應(yīng)該容易理解

一些實(shí)用的建議

1.宣傳教育

2.回顧架構(gòu)

3.完成標(biāo)準(zhǔn)

4.分配軟件架構(gòu)角色

5.架構(gòu)培訓(xùn)班

推動(dòng)變革發(fā)生

軟件架構(gòu)的本質(zhì)

第67章問(wèn)題

PartVP金融風(fēng)險(xiǎn)系統(tǒng)

第68章金融風(fēng)險(xiǎn)系統(tǒng)

背景

交易數(shù)據(jù)系統(tǒng)

參考數(shù)據(jù)系統(tǒng)

功能需求

非功能需求

性能

可伸縮性

可用性

故障轉(zhuǎn)移

安全性

審計(jì)

容錯(cuò)和恢復(fù)

國(guó)際化和木地化

監(jiān)測(cè)和管理

數(shù)據(jù)保存和歸檔

互操作性

PartVIII附錄：“技術(shù)部落”的軟件指南

介紹

語(yǔ)境

用戶

外部系統(tǒng)

功能性概覽

人和部落

內(nèi)容

用戶

博弈引擎

質(zhì)量屬性

性能

可伸縮性

安全性

可用性

國(guó)際化

本地化

瀏覽器兼容性

約束

預(yù)算

原則

組件封裝

自動(dòng)化測(cè)試

酉己置

Spring自動(dòng)裝酉己

軟件架構(gòu)

容器

組件：內(nèi)容更新器

組件：核心

基礎(chǔ)設(shè)施架構(gòu)

線上環(huán)境

部署

軟件

構(gòu)建“技術(shù)部落”

部署“技術(shù)部落”

配置

運(yùn)營(yíng)和支持

啟動(dòng)MySQL

啟動(dòng)MongoDB

啟動(dòng)Web服務(wù)器

啟動(dòng)內(nèi)容更新器

監(jiān)測(cè)

備份

PartI什么是軟件架構(gòu)

通過(guò)學(xué)習(xí)這部分，我們將了解軟件架構(gòu)是什么，架構(gòu)和設(shè)計(jì)的區(qū)別，敏捷的架構(gòu)意味著什

么，以及為什么思考軟件架構(gòu)很重要。

第1章什么是架構(gòu)

在不同的人眼里“架構(gòu)”一詞的意思大相徑庭，互聯(lián)網(wǎng)上對(duì)架構(gòu)的定義也多如牛毛。過(guò)去幾

年里我問(wèn)過(guò)上百人同一個(gè)問(wèn)題，在他們看來(lái)“架構(gòu)"意味著什么。得到的答案概括如下（排

名不分先后）：

?模塊、連接、依賴和接口；

?大局觀；

?改變成本很高的事情；

?難以改變的事情；

?更加兼顧全局的設(shè)計(jì)；

?接口而非實(shí)現(xiàn)；

?審美（比如：藝術(shù)般的整潔代碼）：

?概念模型；

?滿足非功能需求/質(zhì)量屬性；

?每件事都有“架構(gòu)"；

?溝通能力（抽象、語(yǔ)言、詞匯）；

?計(jì)戈也

?一定程度的嚴(yán)格和可靠性；

?藍(lán)圖;

?系統(tǒng)、子系統(tǒng)、交互和接口;

?管理；

?戰(zhàn)略決策的產(chǎn)出；

?必要的約束；

?結(jié)構(gòu)（組件和交互）；

?技術(shù)方向；

?戰(zhàn)略和愿景；

?結(jié)構(gòu)單元；

?實(shí)現(xiàn)目標(biāo)的過(guò)程；

?標(biāo)準(zhǔn)和準(zhǔn)則；

?整個(gè)系統(tǒng)；

?工具和方法；

?從需求到最終產(chǎn)品的道路；

?指導(dǎo)原則；

?技術(shù)領(lǐng)導(dǎo)力；

?構(gòu)成產(chǎn)品的元素之間的關(guān)系;

?對(duì)環(huán)境約束和限制的意識(shí)；

?基礎(chǔ)；

?抽象的觀點(diǎn)；

?把問(wèn)題化整為零的過(guò)程；

?產(chǎn)品的骨架、支柱。

難怪找不到一個(gè)合適的定義！好在還可以分為名詞和動(dòng)詞兩大類。無(wú)論我們談?wù)摰氖墙ㄔ?/p>

一個(gè)物理建筑或一個(gè)軟件系統(tǒng)，都適用。

作為名詞

架構(gòu)作為名詞來(lái)解釋時(shí)，概括起來(lái)都與結(jié)構(gòu)有關(guān)：將產(chǎn)品分解為一系列組件、模塊和交互。

這需要考慮整個(gè)產(chǎn)品，包括處理（建筑物的）供電、供水、空調(diào)，或處理（軟件的）安全、

配置、錯(cuò)誤處理等橫切關(guān)注點(diǎn)的基礎(chǔ)設(shè)施服務(wù)。

作為動(dòng)詞

架構(gòu)作為動(dòng)詞來(lái)解釋時(shí)，包括了理解你需要構(gòu)建什么、設(shè)定愿景以便于進(jìn)行構(gòu)建和做出恰

當(dāng)?shù)脑O(shè)計(jì)決策。所有這些都要以需求為基礎(chǔ)，因?yàn)樾枨篁?qū)動(dòng)架構(gòu)。關(guān)鍵在于，架構(gòu)是關(guān)

于交流愿景以及引入技術(shù)領(lǐng)導(dǎo)力的，這樣參與構(gòu)建產(chǎn)品的每個(gè)人都能理解這個(gè)愿景，并為

產(chǎn)品的成功做出積極貢獻(xiàn)。

第2章架構(gòu)的種類

單是IT行業(yè)就有很多不同種類的架構(gòu)和架構(gòu)師。下面列出了人們?cè)诒粏?wèn)及該問(wèn)題時(shí)給出

的最普遍回答（排名不分先后）：

?基礎(chǔ)設(shè)施；

?安全；

?技術(shù)；

?解決方案；

?網(wǎng)絡(luò)；

?數(shù)據(jù)；

?硬件；

?企業(yè)；

?應(yīng)用程序；

?系統(tǒng);

?集成;

?IT；

?數(shù)據(jù)庫(kù)；

?信息；

?流程；

?商務(wù)；

?軟件。

有些遺憾的是，這個(gè)列表中的有些詞，特別是其定義相互依賴的，比其他詞容易定義。比

如，"解決方案架構(gòu)”到底是什么意思？對(duì)一些組織來(lái)說(shuō)，"解決方案架構(gòu)師"就是"軟件架構(gòu)

師”，而有些組織則有一個(gè)特定的專注于整體“方案”設(shè)計(jì)（但不包括實(shí)施細(xì)節(jié)的討論）的

角色。類似地，"技術(shù)架構(gòu)”通常指軟件、硬件，或者兩者兼有。

有趣的是，當(dāng)我請(qǐng)人們列出他們知道的IT架構(gòu)種類時(shí)，"軟件架構(gòu)”往往是最后被提及的。

這或許反映了這個(gè)詞帶給人們的困惑。

它們的共同點(diǎn)是什么

那么，所有這些詞有什么共同點(diǎn)呢？除了都以“架構(gòu)"或“架構(gòu)師"結(jié)尾之外，所有架構(gòu)類型

都具有結(jié)構(gòu)和愿景。

以“基礎(chǔ)設(shè)施架構(gòu)”為例，想象你要在兩個(gè)辦公室之間建立網(wǎng)絡(luò)連接，而這兩個(gè)辦公室遠(yuǎn)隔

千里。一種做法是找一卷最長(zhǎng)的網(wǎng)線，然后從一個(gè)辦公室直接連接到另一個(gè)辦公室。假設(shè)

你有足夠的線纜，這可能行得通，但現(xiàn)實(shí)中為了達(dá)到這個(gè)目標(biāo)，你要考慮很多環(huán)境約束和

非功能特性。這就是架構(gòu)的過(guò)程以及設(shè)定實(shí)現(xiàn)目標(biāo)愿景的重要之處。

采用一條很長(zhǎng)的線纜是一種方法，但由于現(xiàn)實(shí)世界的約束，這個(gè)方法并不可行。因?yàn)檫@個(gè)

原因，網(wǎng)絡(luò)往往要復(fù)雜得多，需要一組協(xié)同工作的組件來(lái)滿足目標(biāo)。那么從基礎(chǔ)設(shè)施的角

度出發(fā)，我們談?wù)摻Y(jié)構(gòu)時(shí)你期望看到的是這一領(lǐng)域內(nèi)的通用組件，比如路由器、防火墻、

包整形器、交換機(jī)等。

不管你是構(gòu)建軟件系統(tǒng)、網(wǎng)絡(luò)還是數(shù)據(jù)庫(kù)，任何成功的方案都需要你理解問(wèn)題，并設(shè)定一

個(gè)愿景可以和每個(gè)參與構(gòu)建最終產(chǎn)品的人溝通。不論何種領(lǐng)域的架構(gòu)，其實(shí)主要就是結(jié)

構(gòu)和愿景.

第3章軟件架構(gòu)是什么

乍一看，"軟件架構(gòu)”似乎很容易定義。它就是講軟件的架構(gòu)，對(duì)吧？沒(méi)錯(cuò)，但它并不局限

于軟件。

應(yīng)用程序架構(gòu)

對(duì)于我們軟件開發(fā)者來(lái)說(shuō)，最熟悉的應(yīng)該是應(yīng)用程序架構(gòu)，特別是通常由單一技術(shù)編寫的

"應(yīng)用程序"（比如Java網(wǎng)絡(luò)應(yīng)用程序、Windows桌面應(yīng)用程序，等等）。應(yīng)用程序架構(gòu)

的關(guān)注點(diǎn)是應(yīng)用程序，通常包括將應(yīng)用程序解構(gòu)為類和組件，確保設(shè)計(jì)模式的正確應(yīng)用，

構(gòu)建或使用框架，等等。本質(zhì)上，應(yīng)用程序架構(gòu)談?wù)摰氖擒浖O(shè)計(jì)的低級(jí)別切面，通常只

考慮單一的技術(shù)棧（比如Java、微軟.NET等）。

結(jié)構(gòu)單元主要以軟件為基礎(chǔ)，包括編程語(yǔ)言和結(jié)構(gòu)、類庫(kù)、框架、API等。它由類、組件、

模塊、函數(shù)、設(shè)計(jì)模式等加以描述。應(yīng)用程序架構(gòu)著重考慮軟件和代碼組織。

系統(tǒng)架構(gòu)

我喜歡把系統(tǒng)架構(gòu)看作是更大規(guī)模的應(yīng)用程序架構(gòu)。大多數(shù)軟件系統(tǒng)實(shí)際上是由橫跨不同

層次和技術(shù)的多個(gè)應(yīng)用程序組成。舉個(gè)例子，你可能有這樣一個(gè)軟件系統(tǒng)，JavaEE中間

層消費(fèi)Oracle數(shù)據(jù)庫(kù)提供的數(shù)據(jù)，同時(shí)向.NETSilverlight客戶端提供Web服務(wù)。每個(gè)部

分都有自己的應(yīng)用程序架構(gòu)。

要讓整個(gè)軟件系統(tǒng)工作起來(lái)，就要思考如何組合這些單獨(dú)的應(yīng)用程序。換句話說(shuō)，要有端

到端軟件系統(tǒng)在較高層次上的整體結(jié)構(gòu)。另外，大多數(shù)軟件系統(tǒng)都不是孤立的，因此系統(tǒng)

架構(gòu)還關(guān)注互操作性和與環(huán)境中其他系統(tǒng)的集成。

結(jié)構(gòu)單元就是各種軟硬件，從編程語(yǔ)言和軟件框架到服務(wù)器和基礎(chǔ)設(shè)施。跟應(yīng)用程序架構(gòu)

相比，系統(tǒng)架構(gòu)描述為從組件和服務(wù)到子系統(tǒng)等更高層次的抽象。系統(tǒng)架構(gòu)的定義大多數(shù)

都包括了軟件和硬件。畢竟，一個(gè)成功的軟件系統(tǒng)離不開硬件，即使是云上的虛擬硬件。

軟件架構(gòu)

應(yīng)用程序和系統(tǒng)架構(gòu)相對(duì)較容易理解，但人們對(duì)“軟件架構(gòu)”一詞的理解不盡相同。我想把

軟件架構(gòu)定義得盡可能簡(jiǎn)單，而不去受制于各種定義的復(fù)雜性和細(xì)微差別。對(duì)我而言，軟

件結(jié)構(gòu)就是應(yīng)用程序和系統(tǒng)架構(gòu)的結(jié)合。

換句話說(shuō)，從代碼結(jié)構(gòu)和基礎(chǔ)到將代碼成功部署到生產(chǎn)環(huán)境，與一個(gè)軟件系統(tǒng)重要元素相

關(guān)的所有東西就是軟件架構(gòu)。從開發(fā)者的角度考慮軟件開發(fā)，關(guān)注點(diǎn)多數(shù)會(huì)放在代碼上。

在這里，我們考慮的是有助于構(gòu)架更好軟件的東西，比如面向?qū)ο蟮脑瓌t、類、接口、控

制反轉(zhuǎn)、重構(gòu)、自動(dòng)化單元測(cè)試、代碼整潔和其他不勝枚舉的技術(shù)實(shí)踐。如果你團(tuán)隊(duì)里的

人都只考慮這些，那么誰(shuí)來(lái)考慮其他事情？

?橫切關(guān)注點(diǎn)，比如登錄和異常處理；

?安全性，包括認(rèn)證、授權(quán)和敏感數(shù)據(jù)保密；

?性能、可伸縮性、可用性和其他質(zhì)量屬性；

?審計(jì)及其他監(jiān)管需求；

?客觀環(huán)境的約束；

?互操作性、與其他軟件系統(tǒng)的集成；

?運(yùn)營(yíng)、支持和維護(hù)的需求；

?結(jié)構(gòu)和整個(gè)代碼庫(kù)解決問(wèn)題、實(shí)現(xiàn)特性的方法的一致性；

?評(píng)估正在構(gòu)建的基礎(chǔ)有助于交付按計(jì)劃進(jìn)行。

有時(shí)你需要退一步，遠(yuǎn)離代碼和你的開發(fā)工具。這并不意味著低層次的細(xì)節(jié)不重要，因?yàn)?/p>

可用的軟件最終還是要靠交付可運(yùn)行的代碼。細(xì)節(jié)同樣重要，但就大局而言，對(duì)軟件的整

體視角可以確保你的代碼符合整體愿景而非背道而馳。

企業(yè)架構(gòu)：戰(zhàn)略而非代碼

企業(yè)架構(gòu)一般是指整個(gè)組織的中心工作，著眼于如何組織與利用人員、流程和技術(shù)來(lái)使企

業(yè)有效和高效地工作。換句話說(shuō)，它是關(guān)于企業(yè)如何分成組或部門，業(yè)務(wù)流程如何在上層

運(yùn)作，以及技術(shù)如何支撐這一切。這跟軟件架構(gòu)形成了強(qiáng)烈對(duì)比，因?yàn)槠髽I(yè)架構(gòu)沒(méi)有必要

關(guān)注技術(shù)細(xì)節(jié)。相反，企業(yè)架構(gòu)可能看重的是如何在整個(gè)組織中最好地利用技術(shù)，而無(wú)需

實(shí)際介入這些技術(shù)的工作原理。

有些開發(fā)者和軟件架構(gòu)師把企業(yè)架構(gòu)看作職業(yè)發(fā)展的下一站，然而大多數(shù)人卻并非如此。

從事企業(yè)架構(gòu)工作所需要的思維方式和軟件架構(gòu)大相徑庭，對(duì)于技術(shù)及其在組織中的應(yīng)用,

視角很不一樣。企業(yè)架構(gòu)需要更高層次的抽象。這關(guān)乎廣度而非深度，關(guān)乎戰(zhàn)略而非代碼。

第4章敏捷軟件架構(gòu)是什么

以我的經(jīng)驗(yàn)，人們用"敏捷”一詞指代的往往不止一件事情。首當(dāng)其沖就是軟件開發(fā)的敏捷

方法1；快速行動(dòng)，擁抱變化，持續(xù)交付，接收反饋，不一而足。與敏捷思維模式相關(guān)

的第二個(gè)意思是，人們?nèi)绾卧诿艚莪h(huán)境中一起工作，通常包括了團(tuán)隊(duì)動(dòng)態(tài)、系統(tǒng)思維、心

理學(xué)以及其他可能會(huì)跟創(chuàng)建高效團(tuán)隊(duì)聯(lián)系在一起的事情。

1http:〃

先把后面提到的這些“膚淺的東西”放到一邊，在我看來(lái)，給軟件架構(gòu)打上“敏捷"的標(biāo)簽就

意味著它能夠應(yīng)對(duì)所處環(huán)境中的變化，適應(yīng)人們提出的不斷變化的需求。這跟敏捷團(tuán)隊(duì)創(chuàng)

建的軟件架構(gòu)不盡相同。以敏捷方式交付軟件并不能保證得到的軟件架構(gòu)是敏捷的。事實(shí)

上，以我的經(jīng)驗(yàn)，發(fā)生相反的事情通常是因?yàn)閳F(tuán)隊(duì)更關(guān)注交付功能，而非架構(gòu)。

理解“敏捷”

要理解你的軟件架構(gòu)需要多敏捷，就應(yīng)該看看敏捷究竟是什么。美國(guó)空軍戰(zhàn)斗機(jī)飛行員約

翰?博伊德（JohnBoyd）提出了一個(gè)名為00DA循環(huán)的概念2。本質(zhì)上，這個(gè)循環(huán)構(gòu)成了

基本的決策過(guò)程。想象一下，你是一個(gè)正與敵人纏斗的戰(zhàn)斗機(jī)飛行員。為了擊敗對(duì)手，你

需要觀察情況，確定自己的方位（比如做一些分析），決定做什么，并采取行動(dòng)。在激烈

的戰(zhàn)斗中，為避免被對(duì)手擊落，這個(gè)循環(huán)要執(zhí)行得盡可能快。博伊德說(shuō)，如果你能洞悉對(duì)

手的OODA循環(huán)，執(zhí)行得比他更快，就能混淆視聽，誤導(dǎo)對(duì)手。如果你比對(duì)手更敏捷，

就能成為最后的贏家。

2/wiki/OODAloop觀察、定向、決策和行動(dòng)，Observe、

Orient、Decide、Act?

在一篇題為"WhatLessonsCantheAgileCommunityLearnfromAMaverick3FighterPilot"

（敏捷社區(qū)能從特立獨(dú)行的戰(zhàn)斗機(jī)飛行員身上學(xué)到什么）4的論文中，不列顛哥倫比亞大

學(xué)的史蒂夫?阿道夫引用了博伊德的概念，將其應(yīng)用于軟件開發(fā)，得出的結(jié)論是敏捷是相

對(duì)的，且按時(shí)間來(lái)衡量。如果你的軟件團(tuán)隊(duì)交付的軟件跟不上所處環(huán)境的變化，就不算敏

捷。如果你在一個(gè)龐大而行動(dòng)緩慢、鮮有改變的組織中工作，很可能交付軟件要花費(fèi)數(shù)月,

卻仍被組織認(rèn)為是“敏捷”的；在一個(gè)精益初創(chuàng)團(tuán)隊(duì)中，情況多半就不一樣了。

3Maverick是電影《壯志凌云》中湯姆?克魯斯飾演的飛行員的代號(hào)。

4http:〃/xpl/articleDetails.jsp?tp=&amumber=1667567

好的架構(gòu)帶來(lái)敏捷

產(chǎn)生這個(gè)討論的動(dòng)力是好的軟件架構(gòu)能帶來(lái)敏捷。盡管面向服務(wù)的架構(gòu)（S0A5）因?yàn)檫^(guò)

于復(fù)雜、臃腫和粗糙的實(shí)現(xiàn)而被一些組織看作骯臟的詞匯，但軟件系統(tǒng)由小型微服務(wù)6

構(gòu)成仍呈一種增長(zhǎng)趨勢(shì)，每個(gè)服務(wù)只專注做好一件事。一個(gè)微服務(wù)通?？赡懿坏?00行

代碼。如果需要改變，服務(wù)可以用另一種語(yǔ)言重新編寫。這種架構(gòu)風(fēng)格以多種方式提供了

敏捷。小型、松耦合的組件和服務(wù)可以孤立地構(gòu)建、修改和測(cè)試，甚至根據(jù)需求變化移除

和替換。因?yàn)槟軌蚣尤胄陆M件、服務(wù)并在需要時(shí)擴(kuò)展，這種架構(gòu)風(fēng)格也很適合非常靈活和

可適配的部署模型。

5Service-OrientedArchitecture,/wiki/Service.

orientedarchitecture。

6/presentations/Micro-Services

然而，天上不會(huì)掉餡餅。構(gòu)建一個(gè)這樣的軟件系統(tǒng)需要時(shí)間、精力和準(zhǔn)則。很多人也不需

要這種水平的適應(yīng)性和敏捷性，這就是為什么你看到那么多團(tuán)隊(duì)構(gòu)建的軟件系統(tǒng)實(shí)際上整

體感強(qiáng)得多，各部分捆綁在一起并以單一單元部署。盡管更易于構(gòu)建，然而這種架構(gòu)風(fēng)格

在面對(duì)變化的需求時(shí)通常要花費(fèi)更多精力去適配，因?yàn)楣δ芡豢椩诖a庫(kù)中。

二卷體架構(gòu)緣于服務(wù)的架構(gòu)f、

（S0/7,微服分，\

1（通常是單一部署

\單兀的一團(tuán)亂麻）箸等，分別部署）

V

■

介于胡者之間

（例如,單一部署單元的組件）

不同的軟件架構(gòu)提供不同層次的敏捷

在我看來(lái)，兩種架構(gòu)風(fēng)格各有優(yōu)缺點(diǎn)，應(yīng)該在權(quán)衡利弊之后，再?zèng)Q定是構(gòu)架一個(gè)整體系統(tǒng)

還是幾個(gè)微系統(tǒng)。和IT行業(yè)中所有的事情一樣，在這兩者之間也有中間地帶。抱著實(shí)用

主義的想法，你總能選擇構(gòu)建一個(gè)由很多定義好的小組件構(gòu)成，但仍作為單一單元部署的

軟件系統(tǒng)。這也讓你有可能在將來(lái)輕松地遷移到微服務(wù)架構(gòu)。

你需要有多敏捷

理解組織或業(yè)務(wù)變化的速度很重要，因?yàn)檫@能幫助你決定采用何種架構(gòu)風(fēng)格，可能是整體

架構(gòu)、微服務(wù)架構(gòu)或者介于兩者之間。要理解這種權(quán)衡并做出相應(yīng)的選擇。敏捷不是白來(lái)

的。

第5章架構(gòu)對(duì)上設(shè)計(jì)

如果架構(gòu)是關(guān)于結(jié)構(gòu)和愿景的，那設(shè)計(jì)又是什么？如果你在創(chuàng)建一個(gè)解決問(wèn)題的方案，這

不就是設(shè)計(jì)嗎？如果確實(shí)如此，那設(shè)計(jì)和架構(gòu)有什么區(qū)別？

找出區(qū)別

對(duì)于架構(gòu)和設(shè)計(jì)的區(qū)別，格雷迪?布奇(GradyBooch)有一個(gè)常被引用的定義，可以很好

地回答這個(gè)問(wèn)題。在OnDesignl一文中，他說(shuō)道：

1原文給出的鏈接

http:〃./index.jsp?page=Blog&part=2006已失

效，可訪問(wèn)

https:〃/developerworks/community/blogs/gradybooch/entry/ondesign?

lang=en閱讀文章。

作為名詞，設(shè)計(jì)是指一個(gè)系統(tǒng)內(nèi)命名的(盡管有時(shí)無(wú)法命名)結(jié)構(gòu)或行為，解決或有

助于解決該系統(tǒng)的一個(gè)或多個(gè)問(wèn)題。因而設(shè)計(jì)代表了潛在的決策空間中的一個(gè)點(diǎn)。

思考任何一個(gè)需要解決的問(wèn)題，可能都有101種方法。以你目前的軟件項(xiàng)目為例，要實(shí)

現(xiàn)同一目標(biāo)，可能有多種不同的技術(shù)、部署平臺(tái)和設(shè)計(jì)方法可選。即使是設(shè)計(jì)軟件系統(tǒng)，

你的團(tuán)隊(duì)也只是從潛在決策空間里的很多個(gè)點(diǎn)中選擇一個(gè)。

格雷迪還說(shuō)：

所有架構(gòu)都是設(shè)計(jì)，但并非所有設(shè)計(jì)都是架構(gòu)。

這很有道理，因?yàn)閯?chuàng)建一個(gè)解決方案本質(zhì)上就是一次設(shè)計(jì)練習(xí)。然而，出于某些原因，有

一個(gè)區(qū)別使得并非所有設(shè)計(jì)都是“架構(gòu)”，對(duì)此他聲明：

架構(gòu)反映了使一個(gè)系統(tǒng)成型的重要設(shè)計(jì)決策，而重要性則通過(guò)改變的成本來(lái)衡量。

從本質(zhì)上講，格雷迪認(rèn)為重要決策即"架構(gòu)"，其他的都是“設(shè)計(jì)”。在現(xiàn)實(shí)世界中，架構(gòu)和

設(shè)計(jì)的區(qū)別并不明顯，但該定義確實(shí)為我們提供了一個(gè)基準(zhǔn)，去思考在我們的軟件系統(tǒng)中

哪些可能是重要的（或者說(shuō)“架構(gòu)的。比如說(shuō)，這可能包括：

?系統(tǒng)的形態(tài)（例如，客戶端-服務(wù)器、基于Web、原生移動(dòng)客戶端、分布式、

異步，等等）；

?軟件系統(tǒng)的結(jié)構(gòu)（例如，組件、層、交互，等等）；

?技術(shù)選擇（即編程語(yǔ)言、部署平臺(tái)，等等）；

?框架選擇（例如，WebMVC2框架、持久性/0RM3框架，等等）；

?設(shè)計(jì)方法/模式選擇（例如，針對(duì)性能、可伸縮性、可用性等的方法）。

2Model-View-Controller,模型-視圖-控制器。

3Object-RelationalMapping,對(duì)象關(guān)系映射。

架構(gòu)決策不可能輕易反悔，那會(huì)大費(fèi)周章?；蛘哒f(shuō)直白點(diǎn)，架構(gòu)決策很難在一個(gè)下午就完

成重構(gòu)。

理解意義

后退一步想想哪些對(duì)你的軟件系統(tǒng)很重要，這往往是值得的。例如，很多團(tuán)隊(duì)使用關(guān)系型

數(shù)據(jù)庫(kù)，這個(gè)選擇可能被認(rèn)為很重要。為了減少在數(shù)據(jù)庫(kù)技術(shù)變化時(shí)必要的返工量，很多

團(tuán)隊(duì)會(huì)使用Hibernate或EntityFramework這樣的ORM框架。引入額外的ORM層使得

數(shù)據(jù)庫(kù)操作能與代碼的其他部分解耦，而且理論上，不用花費(fèi)很多精力就能獨(dú)立地切換數(shù)

據(jù)庫(kù)。

引入額外層的決策是將某個(gè)部分從軟件系統(tǒng)中解耦的經(jīng)典技術(shù)，促進(jìn)了低耦合、高內(nèi)聚和

更好的關(guān)注點(diǎn)分離。此外，有了ORM以后，可能一個(gè)下午就完成了數(shù)據(jù)庫(kù)的切換。從這

一點(diǎn)來(lái)說(shuō)，從架構(gòu)上它不會(huì)再被看作是重要的。

然而，當(dāng)數(shù)據(jù)庫(kù)的選擇可能不再被當(dāng)作重要決策時(shí)，通過(guò)引入額外層實(shí)現(xiàn)解耦就應(yīng)該是重

要決策。如果你想知道為什么，試想把你當(dāng)前所用的ORM或WebMVC框架完全替換成

另一個(gè)，要花多長(zhǎng)時(shí)間。當(dāng)然，你可以在所選的ORM上再添加其他層，以隔離業(yè)務(wù)邏輯,

并提供輕松替換ORM的敏捷性。但是，你又做出了另一個(gè)重要決策：引入了額外的分層、

復(fù)雜性和成本。

盡管"重要決策"沒(méi)法徹底消失，但能通過(guò)架構(gòu)分層等多種策略來(lái)改變。軟件系統(tǒng)架構(gòu)流程

的一部分就是搞清楚哪些是重要的及為什么。

第6章軟件架構(gòu)重要嗎

那么，軟件架構(gòu)重要嗎？敏捷和軟件工藝運(yùn)動(dòng)幫助提升了我們構(gòu)建的軟件系統(tǒng)的品質(zhì)，這

非常好。它們一起幫助我們?cè)谥?jǐn)慎管理時(shí)間和預(yù)算限制的同時(shí)，寫出更好、更能滿足業(yè)務(wù)

需求的軟件。但是我們能做得更多，因?yàn)榧词故巧倭康能浖軜?gòu)，也能幫助預(yù)防項(xiàng)目的很

多問(wèn)題。成功的軟件項(xiàng)目不僅僅是好的代碼，有時(shí)候你要暫時(shí)跳出代碼，總覽大局。

缺乏軟件架構(gòu)將引發(fā)問(wèn)題

既然軟件架構(gòu)是關(guān)于結(jié)構(gòu)和愿景的，那你可以說(shuō)它總是存在的。我同意，確實(shí)如此。說(shuō)了

這么多，顯而易見(jiàn)，不思考軟件架構(gòu)（以及“大局”）會(huì)導(dǎo)致團(tuán)隊(duì)經(jīng)常遭遇一些常見(jiàn)問(wèn)題。

問(wèn)問(wèn)你自己下面這些問(wèn)題：

?你的軟件系統(tǒng)有良好定義的結(jié)構(gòu)嗎？

?團(tuán)隊(duì)里每個(gè)人都以一致的方式實(shí)現(xiàn)特性嗎？

?代碼庫(kù)的質(zhì)量水平一致嗎？

?對(duì)于如何構(gòu)建軟件，團(tuán)隊(duì)有共同的愿景嗎？

?團(tuán)隊(duì)里每個(gè)人都得到了足夠的技術(shù)指導(dǎo)嗎？

?有適當(dāng)?shù)募夹g(shù)領(lǐng)導(dǎo)力嗎？

如果上面某些問(wèn)題的答案是“不"，那就需要很好的團(tuán)隊(duì)和很好的運(yùn)氣才可能成功地交付一

個(gè)軟件項(xiàng)目。如果沒(méi)人思考軟件架構(gòu)，最終結(jié)果往往看起來(lái)像一團(tuán)亂麻(bigballofmud)

1o當(dāng)然，會(huì)有一個(gè)結(jié)構(gòu)，但不是你想要的！其他副作用還包括軟件系統(tǒng)太慢、不安全、

脆弱、不穩(wěn)定、難以部署、難以維護(hù)、難以改變、難以擴(kuò)展，等等。我敢肯定你從沒(méi)見(jiàn)過(guò)

或參與過(guò)這樣的軟件項(xiàng)目，對(duì)嗎？你沒(méi)有，我也沒(méi)有。

1:http:〃/mud/。

既然軟件架構(gòu)是每個(gè)軟件系統(tǒng)都固有的，那我們?yōu)槭裁床桓纱喑姓J(rèn)這一點(diǎn)，放一些心思在

上面？

軟件架構(gòu)的好處

思考軟件架構(gòu)能帶來(lái)哪些好處？總結(jié)如下:

?讓團(tuán)隊(duì)跟隨一個(gè)清晰的愿景和路線圖，無(wú)論這個(gè)愿景是一人所有還是整個(gè)團(tuán)隊(duì)

共有；

?技術(shù)領(lǐng)導(dǎo)力和更好的協(xié)調(diào)；

?與人交流的刺激因素，以便回答與重要決策、非功能需求、限制和其他橫切關(guān)

注點(diǎn)相關(guān)的問(wèn)題；

?識(shí)別和減輕風(fēng)險(xiǎn)的框架；

?方法和標(biāo)準(zhǔn)的一致性，隨之而來(lái)的結(jié)構(gòu)良好的代碼庫(kù)；

?正在構(gòu)建的產(chǎn)品的堅(jiān)實(shí)基礎(chǔ)；

?對(duì)不同的聽眾，以不同層次的抽象來(lái)交流解決方案的結(jié)構(gòu)。

所有軟件項(xiàng)目都需要軟件架構(gòu)嗎

我不會(huì)給出“看情況”這種典型的咨詢式回答，相反我會(huì)說(shuō)答案毫無(wú)疑問(wèn)是肯定的，并提醒

每個(gè)軟件項(xiàng)目都應(yīng)該考慮多種因素，以評(píng)估必需多少軟件架構(gòu)的思考。這些包括了項(xiàng)目/

產(chǎn)品的大小、項(xiàng)目/產(chǎn)品的復(fù)雜性、團(tuán)隊(duì)的大小和團(tuán)隊(duì)的經(jīng)驗(yàn)。對(duì)于多少是“剛剛好"，將

在本書其他部分探討。

第7章問(wèn)題

1.你知道“架構(gòu)”都說(shuō)些什么嗎？你所在團(tuán)隊(duì)的其他人知道嗎？你所在組織的其他人呢？

2.IT領(lǐng)域有很多不同類型的架構(gòu)。它們有什么共同之處？

3.你和團(tuán)隊(duì)對(duì)“軟件架構(gòu)”的含義有一個(gè)標(biāo)準(zhǔn)定義嗎？你能夠輕松地向團(tuán)隊(duì)的新成員解釋嗎？

這個(gè)定義在你所在組織通用嗎？

4.如果用“敏捷”來(lái)描述一個(gè)軟件的架構(gòu)，是什么意思？你如何面向“敏捷”進(jìn)行設(shè)計(jì)？

5.你能夠把你當(dāng)前軟件項(xiàng)目所做的架構(gòu)決策列一個(gè)清單嗎？它們被視為重要的原因明顯嗎？

6.如果從代碼后退一步，你的軟件系統(tǒng)的“大局”中包含了哪些事情？

7.你所在組織的技術(shù)職業(yè)發(fā)展怎么樣？企業(yè)架構(gòu)會(huì)是你的出路嗎？

8.軟件架構(gòu)重要嗎？為什么，好處是什么？你的軟件項(xiàng)目的架構(gòu)足夠嗎？還是太多了？

PartII軟件架構(gòu)的角色

這部分將關(guān)注軟件架構(gòu)的角色，包括軟件架構(gòu)的角色是什么，需要哪類技能，以及為什么

編碼、指導(dǎo)和合作很重要。

第8章軟件架構(gòu)的角色

要成為一名軟件架構(gòu)師，絕非一夜之間或一次晉升那么簡(jiǎn)單。這是一個(gè)角色，而不是一個(gè)

級(jí)別。這是一個(gè)循序漸進(jìn)的過(guò)程，你會(huì)逐漸獲得這個(gè)角色所需的經(jīng)驗(yàn)和信心。"軟件開發(fā)

者”這個(gè)詞很容易理解，而“軟件架構(gòu)師”則不然。下面是我認(rèn)為構(gòu)成軟件架構(gòu)角色應(yīng)有的

內(nèi)容。注意，我這里說(shuō)的是"角色"；它可以是一個(gè)人，也可以由團(tuán)隊(duì)共同扮演。

、

架構(gòu)驅(qū)動(dòng)力設(shè)計(jì)軟件技術(shù)風(fēng)險(xiǎn)

理解目標(biāo)；抓住、提建立技術(shù)戰(zhàn)略、愿景發(fā)現(xiàn)、減輕和承擔(dān)技

煉、挑戰(zhàn)需求和限制和路線圖術(shù)風(fēng)險(xiǎn)，保證架構(gòu)的

“運(yùn)轉(zhuǎn)”

架構(gòu)演化編寫代碼質(zhì)量保證

貫穿整個(gè)軟件交付過(guò)參與到軟件交付的實(shí)引入并堅(jiān)持標(biāo)準(zhǔn)、指

程，持續(xù)的技術(shù)領(lǐng)導(dǎo)踐部分導(dǎo)、原則等

和對(duì)架構(gòu)的承擔(dān)

軟件架構(gòu)

角色

1.架構(gòu)驅(qū)動(dòng)力

這個(gè)角色首先要理解業(yè)務(wù)目標(biāo)和管理架構(gòu)驅(qū)動(dòng)力，其中包括需求（功能性需求和非功能性

需求）和環(huán)境的限制。軟件項(xiàng)目經(jīng)常糾纏于詢問(wèn)用戶需要什么功能，卻很少問(wèn)他們有哪些

非功能性需求（或質(zhì)量屬性）。有時(shí)候利益相關(guān)者會(huì)告訴我們“系統(tǒng)一定要快"，這太主觀

了。非功能性需求和限制往往對(duì)軟件架構(gòu)有巨大的影響，因此明確地將其納入軟件架構(gòu)的

角色，可以保證它們被考慮到。

2.設(shè)計(jì)軟件

設(shè)計(jì)軟件的過(guò)程是軟件架構(gòu)角色的一部分，這一點(diǎn)應(yīng)該在意料之中。這涉及要理解如何解

決架構(gòu)驅(qū)動(dòng)力帶來(lái)的問(wèn)題，創(chuàng)建軟件系統(tǒng)的整體結(jié)構(gòu)，并為交付設(shè)定一個(gè)愿景。不管你想

做到多敏捷，你可能都需要花一些時(shí)間去明確思考架構(gòu)要如何解決利益相關(guān)者提出的問(wèn)

題，因?yàn)槟愕能浖到y(tǒng)自己搞不定它們。

軟件設(shè)計(jì)的一個(gè)關(guān)鍵部分是技術(shù)選擇，這通常是一個(gè)有趣的練習(xí)，但也有一定的挑戰(zhàn)。例

如，有些組織有一份允許使用的技術(shù)清單，你只能從中選擇，有些組織則規(guī)定不允許使用

特定許可的開源技術(shù)。接下來(lái)是其他所有因素，比如成本、許可、供應(yīng)商關(guān)系、技術(shù)戰(zhàn)略、

兼容性、互操作性、支持、不熟、升級(jí)策略、最終用戶環(huán)境，等等。這些因素?fù)诫s在一起,

常常會(huì)把選擇一個(gè)富客戶端技術(shù)之類的簡(jiǎn)單決策徹底搞成一場(chǎng)噩夢(mèng)。需要有人負(fù)責(zé)這個(gè)技

術(shù)選擇的過(guò)程，這完全屬于軟件架構(gòu)角色的職責(zé)范圍。

3.技術(shù)風(fēng)險(xiǎn)

到目前為止的內(nèi)容可以幫你專注于構(gòu)建好的解決方案，但并不能保證成功。把最好的設(shè)計(jì)

和最好的技術(shù)簡(jiǎn)單地拼湊在一起，并不意味著整個(gè)架構(gòu)就會(huì)成功。你選擇的技術(shù)是否真的

奏效，也是個(gè)問(wèn)題。很多團(tuán)隊(duì)都有“做不如買"的戰(zhàn)略，為了可能會(huì)節(jié)約成本而去使用一些

（商業(yè)或開源的）產(chǎn)品。然而，很多團(tuán)隊(duì)也因?yàn)槁犘殴?yīng)商網(wǎng)站或西裝革履的銷售人員的

宣傳，結(jié)果遭了殃。似乎很少人會(huì)問(wèn)技術(shù)是否真的以設(shè)想的方式工作，能證明的人更少。

技術(shù)選擇其實(shí)就是風(fēng)險(xiǎn)管理，當(dāng)復(fù)雜度或不確定性高的時(shí)候降低風(fēng)險(xiǎn)，有利可圖時(shí)再冒點(diǎn)

險(xiǎn)。所有的技術(shù)決策，在做出選擇時(shí)都要把全部因素考慮在內(nèi)，這些技術(shù)決策也需要評(píng)審

和評(píng)估。這可能包括一個(gè)軟件系統(tǒng)所有的主要結(jié)構(gòu)單元，下至在開發(fā)過(guò)程中引入的庫(kù)和框

架。

你要問(wèn)自己的問(wèn)題是，你的架構(gòu)是否“管用”。對(duì)我來(lái)說(shuō)，一個(gè)架構(gòu)如果能滿足非功能性需

求，在給定的環(huán)境約束下有效，能為其他代碼提供必要的基礎(chǔ)，作為平臺(tái)能解決潛在的業(yè)

務(wù)問(wèn)題，那就是管用的。軟件最大的一個(gè)問(wèn)題就是，它復(fù)雜而抽象，很難通過(guò)圖表甚至代

碼本身可視化一份軟件在運(yùn)行時(shí)的特征。止匕外，我并不總是相信自己第一次就能做好。當(dāng)

然了，說(shuō)不定你可以！

在整個(gè)軟件開發(fā)的生命周期中，為了有信心讓所構(gòu)建的系統(tǒng)在交付時(shí)能正常工作，我們會(huì)

進(jìn)行多種類型的測(cè)試。那為什么不對(duì)架構(gòu)也這樣做？如果能測(cè)試架構(gòu)，我們就能證明它是

管用的。如果可以做得盡可能簡(jiǎn)單，我們就能降低項(xiàng)目失敗的整體風(fēng)險(xiǎn)。架構(gòu)師應(yīng)該像優(yōu)

秀的主廚一樣，品嘗自己生產(chǎn)的東西。概括地說(shuō)，就是主動(dòng)發(fā)現(xiàn)、減輕和承擔(dān)高優(yōu)先級(jí)

的技術(shù)風(fēng)險(xiǎn)，這樣才能保住你的項(xiàng)目和工作。

4.架構(gòu)演化

很多時(shí)候，軟件先被設(shè)計(jì)好，然后交給開發(fā)團(tuán)隊(duì)，實(shí)際上在把軟件開發(fā)當(dāng)作接力運(yùn)動(dòng)來(lái)

處理。結(jié)果適得其反，因?yàn)檫@樣的軟件架構(gòu)需要照顧。得有人看著它，在整個(gè)交付過(guò)程中

依據(jù)不斷變化的需求和團(tuán)隊(duì)反饋來(lái)對(duì)其演化。如果架構(gòu)師創(chuàng)建了一個(gè)架構(gòu)，為什么在整個(gè)

交付過(guò)程的其他時(shí)候不自己擁有和演化這個(gè)架構(gòu)？這關(guān)乎持續(xù)的技術(shù)領(lǐng)導(dǎo)，而不是僅僅參

與生命周期的開始階段，然后泰然處之、袖手旁觀。

5.編寫代碼

我認(rèn)識(shí)的大多數(shù)最優(yōu)秀的軟件架構(gòu)師，都有軟件開發(fā)的背景，但由于種種原因，許多組織

并不認(rèn)為寫代碼是軟件架構(gòu)角色的一部分。做一個(gè)“實(shí)踐派軟件架構(gòu)師”并不一定指涉足日

常的編碼任務(wù)，但確實(shí)意味著你要持續(xù)地參與到交付中，積極地幫助引導(dǎo)和塑造它。說(shuō)了

這么多，為什么日常編碼工作不應(yīng)該是軟件架構(gòu)角色的一部分？

許多軟件架構(gòu)師都是構(gòu)建大師，所以經(jīng)常練手是有意義的。此外，編碼為架構(gòu)師提供了

一種與團(tuán)隊(duì)分享軟件開發(fā)經(jīng)驗(yàn)的方式，從而幫助他們更好地理解如何從開發(fā)的角度看待架

構(gòu)。許多公司都有阻止軟件架構(gòu)師參與編碼工作的政策，因?yàn)樗麄兊募軜?gòu)師“太寶貴了，

不該承擔(dān)日常編碼工作”。這顯然是錯(cuò)誤的，如果你不打算讓軟件架構(gòu)師為成功交付做出

自己的貢獻(xiàn)，為什么還要讓他們?yōu)檐浖O(shè)計(jì)投入全部精力？

當(dāng)然，有些情況下要參與到代碼級(jí)別并不實(shí)際。例如，一個(gè)大型項(xiàng)目通常意味著要照看更

大的“大局”，有可能你根本沒(méi)時(shí)間寫代碼。但是一般來(lái)說(shuō)，一個(gè)寫代碼的軟件架構(gòu)師會(huì)更

有成效也更快樂(lè)。你不應(yīng)該因?yàn)椤拔沂羌軜?gòu)師”，就把自己排除在編碼之外。

6.質(zhì)量保證

即使有了世界上最好的架構(gòu)，糟糕的交付也能讓原本可以成功的軟件項(xiàng)目失敗。質(zhì)量保證

應(yīng)該是軟件架構(gòu)角色的一部分，但它的內(nèi)容不只是代碼評(píng)審。你要保證一條基線，它可以

是引入一些標(biāo)準(zhǔn)和工作實(shí)踐，如編碼標(biāo)準(zhǔn)、設(shè)計(jì)原則和工具。質(zhì)量保證也包括確保團(tuán)隊(duì)對(duì)

架構(gòu)實(shí)現(xiàn)的一致。管它叫架構(gòu)服從還是架構(gòu)一致取決于你，但都要遵循技術(shù)愿景。

可以肯定地說(shuō)，大多數(shù)項(xiàng)目沒(méi)有做足夠的質(zhì)量保證，因此，你要弄清楚什么是重要的，并

確保它有充分的保證。對(duì)我來(lái)說(shuō)，只要是架構(gòu)上顯著的、業(yè)務(wù)上關(guān)鍵的、復(fù)雜的和高度可

見(jiàn)的，都是一個(gè)項(xiàng)目的重要組成部分。你要?jiǎng)?wù)實(shí)地認(rèn)識(shí)到?jīng)]辦法保證每件事。

合作或失敗

一個(gè)軟件系統(tǒng)很少孤立存在，可能有不少人要為整個(gè)架構(gòu)過(guò)程作貢獻(xiàn)。這包括了從需要

理解和認(rèn)同架構(gòu)的直接開發(fā)團(tuán)隊(duì)，一直到那些對(duì)安全性、數(shù)據(jù)庫(kù)、運(yùn)營(yíng)、維護(hù)或支持感興

趣的人組成的擴(kuò)展團(tuán)隊(duì)。任何擔(dān)任軟件架構(gòu)角色的人都需要與這些人合作，以確保架構(gòu)能

與周圍環(huán)境成功整合。如果不合作，就等著失敗吧。

技術(shù)領(lǐng)導(dǎo)是一個(gè)角色而非級(jí)別

軟件架構(gòu)的角色基本上就是向軟件團(tuán)隊(duì)引入技術(shù)領(lǐng)導(dǎo)，有必要重申的是，我這里談?wù)摰氖?/p>

一個(gè)角色，而非職務(wù)級(jí)別。通常，大型組織會(huì)作為對(duì)長(zhǎng)期服務(wù)的獎(jiǎng)勵(lì)，或者因?yàn)橄虢o某人

加薪，而搬出“架構(gòu)師”的頭銜。如果接受這個(gè)頭銜的人具備承擔(dān)這個(gè)角色的能力，那就沒(méi)

問(wèn)題，但情況并不總是如此。如果你訂閱過(guò)Linkedln或StackOverflow的軟件架構(gòu)討論

組，可能見(jiàn)過(guò)類似的問(wèn)題：

嘿，我剛晉升為軟件架構(gòu)師，但我不知道該干些什么。救救我！我要看什么書？

盡管無(wú)法阻擋一些組織讓人晉升到超出其能力的角色，我還是可以描述自己對(duì)軟件架構(gòu)角

色的看法。設(shè)計(jì)軟件可能是這個(gè)角色樂(lè)趣的一部分，但一個(gè)成功的軟件項(xiàng)目遠(yuǎn)不止如此。

提出你自己對(duì)這個(gè)角色的定義

根據(jù)我的經(jīng)驗(yàn)，盡管很多軟件團(tuán)隊(duì)都明白自己需要軟件架構(gòu)這個(gè)角色，卻往往沒(méi)有一個(gè)參

考定義。少了這個(gè)定義，很可能就無(wú)法履行這個(gè)角色的部分或全部職責(zé)。

大多數(shù)跟軟件開發(fā)團(tuán)隊(duì)有關(guān)的角色都比較容易理解一一開發(fā)人員、測(cè)試人員、流程經(jīng)理、

產(chǎn)品所有者、業(yè)務(wù)分析師、項(xiàng)目經(jīng)理，等等。軟件架構(gòu)角色？不清楚。我經(jīng)常問(wèn)軟件團(tuán)隊(duì)

對(duì)軟件架構(gòu)角色有沒(méi)有參考定義，常見(jiàn)的回答不外乎"沒(méi)有"或"有，但我們不用"。同一個(gè)

團(tuán)隊(duì)的人往往會(huì)給出不同答案。

軟件架構(gòu)的必要性通常是公認(rèn)的，但這個(gè)角色的責(zé)任往往并不明確。根據(jù)我的經(jīng)驗(yàn)，這可

能導(dǎo)致沒(méi)有人承擔(dān)這個(gè)角色，或者有人被安排了這個(gè)角色，卻不真正了解應(yīng)該怎么做。如

果沒(méi)有理解角色，就不會(huì)發(fā)揮相應(yīng)的作用，更遑論培養(yǎng)未來(lái)的軟件架構(gòu)師。

不管你怎么稱呼它（比如架構(gòu)師、技術(shù)主管、首席設(shè)計(jì)師等），我的建議都很簡(jiǎn)單。如果

你沒(méi)有什么東西可以用來(lái)表達(dá)"這就是我們對(duì)軟件架構(gòu)師的期望”，花些時(shí)間想想這回事。

首先，對(duì)于對(duì)軟件架構(gòu)角色的期望，要跟你的團(tuán)隊(duì)達(dá)成共識(shí)；然后，如果看到益處，就在

你的組織里對(duì)其標(biāo)準(zhǔn)化。

第9章軟件架構(gòu)師應(yīng)該編碼嗎

既然我創(chuàng)建了一個(gè)叫作編碼架構(gòu)的網(wǎng)站1,我猜這個(gè)問(wèn)題的答案就不出人意料了。在我

理想的世界觀中，軟件架構(gòu)師應(yīng)該編碼。曾經(jīng)有人告訴我，優(yōu)秀架構(gòu)師的重要特征是抽象

思維能力，也可以理解成不把所有時(shí)間都耗在細(xì)節(jié)里的能力。這沒(méi)錯(cuò)，但你畫的那些框框

線線終歸要形成代碼。

1http:〃

編寫代碼

我的建議是讓編碼成為你作為軟件架構(gòu)師角色的一部分，只要把自己當(dāng)作軟件開發(fā)團(tuán)隊(duì)的

一份子就行了。換句話說(shuō)，你有一頂軟件架構(gòu)的帽子和一頂編寫代碼的帽子。你不見(jiàn)得要

成為團(tuán)隊(duì)里寫代碼最厲害的，但參與到實(shí)踐和交付流程的好處非常大。畢竟，"知"和"行”

還是不同的。

團(tuán)隊(duì)欣聞你要貢獻(xiàn)代碼，通常會(huì)受到鼓勵(lì)，確保你的設(shè)計(jì)能落到實(shí)處。如果沒(méi)有，那么一

旦你站在開發(fā)者的角度明白了這個(gè)問(wèn)題，很快就能體會(huì)到那種痛苦。

創(chuàng)建能實(shí)際實(shí)現(xiàn)的軟件架構(gòu)，這樣做的好處顯而易見(jiàn)，除此之外，貢獻(xiàn)代碼還能幫助你和

團(tuán)隊(duì)建立起融洽的關(guān)系，有助于縮短存在于很多軟件團(tuán)隊(duì)的架構(gòu)師和開發(fā)者之間的距離。

引用瑞秋?戴維斯(RachelDavies)和麗茲?賽德利(LizSedley)在《敏捷教練：如何打造

優(yōu)秀的敏捷團(tuán)隊(duì)》2一書中說(shuō)的話：

2http:〃/book/sdcoach/agile-coaching

如果你了解如何編程，往往會(huì)忍不住對(duì)開發(fā)者該如何編寫代碼提出建議。小心，因?yàn)?/p>

你可能在浪費(fèi)時(shí)間：如果你沒(méi)有參與項(xiàng)目的編程，開發(fā)者多半會(huì)無(wú)視你的編碼經(jīng)驗(yàn)。

他們還會(huì)認(rèn)為你越權(quán)，影響了他們的工作，所以盡量別在這方面指指點(diǎn)點(diǎn)。

構(gòu)建原型、框架和基礎(chǔ)

當(dāng)你被看作開發(fā)團(tuán)隊(duì)的一員時(shí)，軟件架構(gòu)的角色可能會(huì)輕松得多，然而有時(shí)這卻不太可能。

晉升或被指定為軟件架構(gòu)師帶來(lái)的一個(gè)問(wèn)題在于，你可能會(huì)發(fā)現(xiàn)自己不能像期望的那樣寫

很多代碼。這可能因?yàn)闀r(shí)間壓力，因?yàn)槟阌泻芏?架構(gòu)”工作要做，或者只是公司政策不允

許你寫代碼，我見(jiàn)過(guò)這樣的情況。如果是這樣的話，對(duì)軟件系統(tǒng)中有疑問(wèn)的概念構(gòu)建原型

和證明是一個(gè)很好的參與方式。這讓你可以和團(tuán)隊(duì)建立起融洽的關(guān)系，也是評(píng)估你的架構(gòu)

是否管用的好辦法。

作為替代，你可以幫助建立團(tuán)隊(duì)可用的框架和基礎(chǔ)。試著抵擋住構(gòu)建好這些東西再交給團(tuán)

隊(duì)的誘惑，因?yàn)檫@樣可能會(huì)適得其反。軟件開發(fā)非常容易趕潮流，所以小心別構(gòu)建出一個(gè)

東西卻被團(tuán)隊(duì)當(dāng)作毫無(wú)價(jià)值的過(guò)時(shí)破爛！

進(jìn)行代碼評(píng)審

顯然沒(méi)有什么能代替給真正的項(xiàng)目編碼，我也不推薦把代碼評(píng)審作為一個(gè)長(zhǎng)期的戰(zhàn)略，但

參與（或做）代碼評(píng)審至少能讓你了解新技術(shù)及其應(yīng)用。對(duì)于你沒(méi)有經(jīng)驗(yàn)的技術(shù)，挑剔或

參與討論可能會(huì)損害你的名聲。我記得自己曾不得不向一個(gè)從未寫過(guò)一行Java代碼的架

構(gòu)師解釋自己的java代碼。那很無(wú)聊。

實(shí)驗(yàn)并與時(shí)俱進(jìn)

你需要保持一定水平的技術(shù)知識(shí)，才能稱職地用它來(lái)進(jìn)行方案設(shè)計(jì)。但是，如果無(wú)法對(duì)交

付做出貢獻(xiàn)，作為架構(gòu)師的你要如何維持編碼技能？

在工作之外你往往有更多的空間來(lái)維持編碼技能，從貢獻(xiàn)開源項(xiàng)目，到不斷嘗試你感興趣

的最新語(yǔ)言、框架、API。書、博客、播客、會(huì)議和聚會(huì)都能達(dá)到這個(gè)目的。但有時(shí)候你

必須跳出代碼。這些事我當(dāng)然都做過(guò)，乘坐公共交通工具長(zhǎng)途通勤的一個(gè)好處是你有時(shí)間

去玩技術(shù)。當(dāng)然了，前提是你經(jīng)過(guò)一天的辛勤工作還不犯困的話！

軟件架構(gòu)師和雇主之間的矛盾

我很幸運(yùn)，我的軟件架構(gòu)角色中有相當(dāng)部分的實(shí)踐元素，大多數(shù)我參與的項(xiàng)目都有我的代

碼。我堅(jiān)定地認(rèn)為，機(jī)會(huì)是自己創(chuàng)造的。我仍然動(dòng)手實(shí)踐的原因可以這樣表述：它是這個(gè)

角色的重要組成部分。對(duì)我來(lái)說(shuō)這很簡(jiǎn)單。設(shè)計(jì)軟件時(shí)，編碼是必不可少的，因?yàn)槲倚枰?/p>

熟悉最新的技術(shù)，搞清楚我設(shè)計(jì)的哪些東西能工作。另外，我得承認(rèn)編碼很有趣。

可惜，許多組織似乎認(rèn)為編碼是軟件開發(fā)過(guò)程中最容易的部分，因此他們通常讓另一個(gè)國(guó)

家的其他人來(lái)做這件事，以為這樣能省錢。好的代碼在這樣的組織看來(lái)也是"低價(jià)值”的。

組織中軟件架構(gòu)師的資歷和編碼工作的價(jià)值就脫節(jié)了，矛盾由此產(chǎn)生。

以我的經(jīng)驗(yàn)，小組織不會(huì)發(fā)生這種事，因?yàn)樾枰耸謺r(shí)每個(gè)人都要參與進(jìn)來(lái)。是的，那些

大型組織里的矛盾最嚴(yán)重。我曾在一個(gè)中等規(guī)模的咨詢公司工作過(guò)一段時(shí)間，我的職位等

級(jí)把我歸入管理團(tuán)隊(duì)，但我仍會(huì)寫代碼。在某些方面，頂著“行政經(jīng)理”的頭銜，又能每天

寫代碼，真是了不起的成績(jī)！但有時(shí)這也讓人很不舒服，因?yàn)槠渌?jīng)理經(jīng)常會(huì)試圖在其組

織架構(gòu)圖里加上我的名字。

陷入這種情況是很麻煩的，只有你自己能擺脫它。無(wú)論你是在一個(gè)正在發(fā)生這種事的組織,

還是想要離開是非之地，都要搞清楚你對(duì)軟件架構(gòu)師這個(gè)角色的看法，并準(zhǔn)備好堅(jiān)守自

己的立場(chǎng)。

你不必放棄編碼

說(shuō)到這一點(diǎn)，我會(huì)經(jīng)常被問(wèn)及“如果軟件架構(gòu)師打算在公司的職業(yè)道路上有所作為，是否

還能繼續(xù)編碼”，也就不奇怪了。這真是羞恥，尤其是如果這些人真的很喜歡他們所做的

技術(shù)。

對(duì)此我的態(tài)度絕對(duì)是肯定的，你可以繼續(xù)寫代碼。對(duì)我來(lái)說(shuō)，聽到人們說(shuō)“好吧，為了成

為架構(gòu)師或在職業(yè)道路上更進(jìn)一步，我明白自己不得不放棄編碼了"，是相當(dāng)令人沮喪的。

有很多組織是這樣的，肯定有很多人被告知組織中的高級(jí)職位不需要寫代碼。

軟件架構(gòu)師在滿足非功能性需求、進(jìn)行技術(shù)質(zhì)量保證、確保軟件符合其用途等方面，要承

擔(dān)很大的責(zé)任。這是一個(gè)領(lǐng)導(dǎo)的角色，編碼（以身作則）是保證項(xiàng)目成功最好的方式之一。

此外，如果軟件架構(gòu)師不保持技術(shù)能力，誰(shuí)來(lái)培養(yǎng)更多未來(lái)的軟件架構(gòu)師？

不要把全部時(shí)間都用于編碼

重申一下我的建議，軟件架構(gòu)師不必放棄編碼。無(wú)論你怎么做，在不斷變化的世界中，編

碼是一個(gè)保持技術(shù)能力的好辦法。很多人認(rèn)為軟件架構(gòu)是一種“后技術(shù)”的職業(yè)選擇，但除

了豐富的經(jīng)驗(yàn)和更寬的知識(shí)面，它還需深厚的技術(shù)能力，需要能夠回答設(shè)計(jì)是否真的管用

這類問(wèn)題的T形人才。把這歸為“實(shí)現(xiàn)細(xì)節(jié)”是不可接受的。只是別把時(shí)間都花在編碼上。

如果你花全部時(shí)間寫代碼，那軟件架構(gòu)角色的其他部分由誰(shuí)來(lái)扮演？

第10章軟件架構(gòu)師應(yīng)該是建造大師

把建筑的隱喻應(yīng)用到軟件不見(jiàn)得合適，盡管在中世紀(jì)，設(shè)計(jì)建筑的人只是極少數(shù)，卻組成

了建造大師的高端社團(tuán)。之所以做這樣的隱喻，是因?yàn)榻ㄔ齑髱熋逼鋵?shí)是他們這門學(xué)問(wèn)

的大師，一旦達(dá)到了這種高度，建造大師是繼續(xù)建造還是讓其他名氣不大的人來(lái)做？幾百

年后，我們似乎又在對(duì)軟件行業(yè)問(wèn)同樣的問(wèn)題。

聯(lián)盟的狀態(tài)

在過(guò)去的十年間，由于“大型預(yù)先設(shè)計(jì)"和"分析麻痹"等問(wèn)題，軟件架構(gòu)已經(jīng)失寵。這多半

源于為了更有效地交付軟件系統(tǒng)，敏捷方法作為主要的催化劑，減少了很多團(tuán)隊(duì)都要做的

預(yù)先思考的工作量，結(jié)果現(xiàn)在“架構(gòu)師”在軟件團(tuán)隊(duì)里往往被看作是多余的。很多團(tuán)隊(duì)都向

著扁平化和自組織努力，從表面上看這不需要再專設(shè)技術(shù)領(lǐng)導(dǎo)。

另一個(gè)因素是，許多人認(rèn)為架構(gòu)師都在做高層次的抽象思維。我相信你已經(jīng)見(jiàn)過(guò)“象牙塔

架構(gòu)師"或"PPT架構(gòu)師”等說(shuō)法，用來(lái)指代那些設(shè)計(jì)解決方案時(shí)從不考慮細(xì)節(jié)的人。如果

我們回顧一下過(guò)去，這可不是架構(gòu)師的角色。

回顧過(guò)去

如果你追溯"架構(gòu)師"(architect)一詞在拉丁語(yǔ)(architectus)和希臘語(yǔ)(arkhitekton)

的源頭，直譯就是“首席建筑師”，從字面上看，這些人是他們這行中的佼佼者。在中世紀(jì),

“建筑師"一詞指"石匠大師"，因?yàn)槭^是當(dāng)時(shí)的主要建筑材料。下面這句話對(duì)這個(gè)角色做

了很好的總結(jié)1:

1http:〃www.moonshadow.co.uk/?p=66

石匠大師，就是石頭的操作者、藝術(shù)家和設(shè)計(jì)師。

這句話同樣適用于我們軟件開發(fā)者。

建造大師真的會(huì)建造嗎

關(guān)鍵問(wèn)題是，建造大師是否真的建造了什么？如果你研究一下人們?nèi)绾螌?shí)現(xiàn)“石匠大師”的

角色，就會(huì)發(fā)現(xiàn)一些類似的東西2：

2http:〃/article/the-medieval-stonemason-and-the-master-mason-a65816

盡管石匠大師受人尊敬、通常也很富有，然而在達(dá)到行業(yè)頂峰之前，他必須經(jīng)歷石匠、

監(jiān)督的歷練來(lái)證明自己的價(jià)值。

架構(gòu)師的維基百科頁(yè)面說(shuō)了相同的話3:

3http:〃/wiki/Architect

在古代和中世紀(jì)的歷史中，大多數(shù)建筑設(shè)計(jì)和建設(shè)都是工匠完成的：下至石匠和木匠,

上至建造大師。

有趣的是，對(duì)于這些石匠大師參與過(guò)多少建筑，并沒(méi)有一個(gè)統(tǒng)一觀點(diǎn)。比如4：

4http:〃www.moonshadow.co.uk/?p=66

他實(shí)際上做了多少，其實(shí)是有爭(zhēng)議的。這個(gè)術(shù)語(yǔ)可能會(huì)有所不同，但是，以我的理解,

中世紀(jì)石匠大師基本的組織和角色跟今天的首席建筑師是類似的：這也許反映了建筑

建造不變的基本。

真正有意義的是看看這個(gè)角色承擔(dān)了什么。引用另一段話5：

5http:〃www.historylearningsite.co.uk/medievalmasons.htm

頂尖的石匠就是一個(gè)石匠大師。然而，建筑大師這個(gè)頭銜，指的是全面負(fù)責(zé)建筑工地、

讓石匠大師們?yōu)樗ぷ鞯哪莻€(gè)人。建筑大師也負(fù)責(zé)木匠、玻璃工匠等。實(shí)際上，每個(gè)

建筑工地上的人都在建筑大師的監(jiān)督下工作。

再加一些額外的細(xì)節(jié)6：

6http:〃www.moonshadow.co.uk/?p=66

然后，石匠大師為將要建造的東西設(shè)計(jì)結(jié)構(gòu)、美學(xué)和象征等方面的特性，組織后勤，

還要評(píng)定工作的優(yōu)先級(jí)并決定它們的順序。

象牙塔

如果這聽起來(lái)很熟悉，等一等，看看團(tuán)隊(duì)過(guò)去是如何工作的7：

7http:〃www.moonshadow.co.uk/?p=66

每一個(gè)小石匠都遵循大師設(shè)定的方向和對(duì)主要結(jié)構(gòu)或美學(xué)的所有決定，解決那些問(wèn)題

都是大師的工作。

顯然，容易看出很多軟件團(tuán)隊(duì)的傳統(tǒng)運(yùn)作方式與此相似，敏捷軟件開發(fā)團(tuán)隊(duì)希望采用一種

不同的方法也就不奇怪了。很多現(xiàn)代的軟件開發(fā)團(tuán)隊(duì)試圖讓一群人分擔(dān)技術(shù)領(lǐng)導(dǎo)者的角色,

而不是安排一個(gè)遠(yuǎn)離細(xì)節(jié)的專門角色。當(dāng)然，很多架構(gòu)師遠(yuǎn)離細(xì)節(jié)的主要原因之一是他們

沒(méi)有時(shí)間。這通常導(dǎo)致架構(gòu)師在現(xiàn)實(shí)的團(tuán)隊(duì)日常工作中被移除，慢慢變得脫離實(shí)際。過(guò)去

的石匠大師也被這個(gè)問(wèn)題困擾8：

8http:〃www.moonshadow.co.uk/?p=66

看起來(lái)同時(shí)進(jìn)行多個(gè)任務(wù)是很平常的事情，石匠大師很少參與體力工作(即使身體條

件允許)也就不足為奇。1261年，尼古拉斯?德?比亞德(NicholasdeBiard)在布道

中斥責(zé)“只靠言語(yǔ)就做判斷，的石匠大師的明顯懶惰，給出了這一假設(shè)的證詞。

下面這段話來(lái)自瑞秋?戴維斯和麗茲?賽德利所著的《敏捷教練：如何打造優(yōu)秀的敏捷團(tuán)隊(duì)》

9,突出了這種現(xiàn)象在軟件行業(yè)中造成的一個(gè)常見(jiàn)后果：

9http:〃/book/sdcoach/agile-coaching

如果你了解如何編程，往往會(huì)忍不住對(duì)開發(fā)者該如何編寫代碼提出建議。小心，因?yàn)?/p>

你可能在浪費(fèi)時(shí)間：如果你沒(méi)有參與項(xiàng)目的編程，開發(fā)者多半會(huì)無(wú)視你的編碼經(jīng)驗(yàn)。

他們還會(huì)認(rèn)為你越權(quán)，影響了他們的工作，所以盡量別在這方面指指點(diǎn)點(diǎn)。

為了掩蓋這種局面，很多人會(huì)把軟件架構(gòu)的角色看作其組織內(nèi)的一個(gè)高級(jí)職位或級(jí)別，從

而加劇了開發(fā)者和架構(gòu)師之間的脫節(jié)?？磥?lái)，石匠大師也有相同的境遇10：

10http:〃www.moonshadow.co.uk/?p=66

為了避免這種爭(zhēng)斗，文藝復(fù)興后期的藝術(shù)家們不再被視為只是普通的工匠，而石匠大

師似乎被神話(在我看來(lái))為貴族后裔。此外，由于對(duì)所掌握知識(shí)秘而不宣，他們制

造了一種神秘感，讓自己有別于其他不那么"神秘"或"高尚"的職業(yè)。

建造大師角色的差異

多數(shù)看法都一樣：建造大師并沒(méi)有太多時(shí)間去建造，盡管他們具備這樣的技能?；氐杰浖?/p>

行業(yè)，軟件架構(gòu)師應(yīng)該寫代碼嗎？我直截了當(dāng)?shù)鼗卮穑?理論上，是的。"更完整的答案可

以在這本書里面找到。為什么？因?yàn)榧夹g(shù)不是一個(gè)實(shí)現(xiàn)細(xì)節(jié)，你需要理解為自己的決定

所做的取舍。

那么現(xiàn)代建筑師為什么不為實(shí)際的建造過(guò)程出力呢？為了回答這個(gè)問(wèn)題，我們要看看這個(gè)

角色這些年是如何演化的11：

11http:〃/wiki/Architect

在古代和中世紀(jì)的歷史中，大多數(shù)建筑設(shè)計(jì)和建設(shè)都是工匠完成的：下至石匠和木匠,

上至建造大師。直到現(xiàn)代，建筑師和工程師之間也沒(méi)有明顯的區(qū)別。在歐洲，建筑師

和工程師的頭銜主要因地域不同而經(jīng)常交替使用，但指的都是同一個(gè)人。

結(jié)構(gòu)工程的維基百科頁(yè)面12提供了更多信息：

12http:〃/wiki/Structuralengineering

自從人類開始修筑屬于自己的結(jié)構(gòu)，結(jié)構(gòu)工程就出現(xiàn)了。在19世紀(jì)末的工業(yè)革命期

間，建筑專業(yè)體現(xiàn)出了與工程專業(yè)的不同，成為一個(gè)更正式的專業(yè)。直到那時(shí):建筑

師和結(jié)構(gòu)工程師通常還是同一個(gè)人：建造大師。19世紀(jì)和20世紀(jì)初，隨著結(jié)構(gòu)理

論專業(yè)知識(shí)的發(fā)展，專門的結(jié)構(gòu)工程師才開始出現(xiàn)。

本質(zhì)上，傳統(tǒng)建筑師的角色已經(jīng)分化為兩種。一種是結(jié)構(gòu)工程師，確保建筑物不倒塌；另

一種是建筑師，負(fù)責(zé)與客戶交流，收集他們的需求，從美學(xué)的視角進(jìn)行建筑設(shè)計(jì)。馬

丁?福勒(MartinFowler)的blikil3有一個(gè)頁(yè)面談到了兩種角色差異的意義：

軟件架構(gòu)師被看作是首席設(shè)計(jì)師，是把項(xiàng)目的每件事凝聚在一起的人。但建筑師可不

會(huì)干這些。建筑師關(guān)注的是與想要建筑的客戶交流。他的精力集中在客戶覺(jué)得重要的

事情上，比如建筑的布局和外觀。但建筑也不僅限于此。

因其背后蘊(yùn)含的包括物理定律在內(nèi)的豐富知識(shí)，建筑現(xiàn)在被看作是一門工程學(xué)科，這些知

識(shí)能夠建模和預(yù)測(cè)建材的行為。相比之下，軟件開發(fā)行業(yè)還比較年輕，正以驚人的速度發(fā)

展。今天的建筑大多還是使用和幾百年前相同的材料，但似乎我們每20分鐘就會(huì)發(fā)明一

種新技術(shù)。我們生活在“互聯(lián)網(wǎng)時(shí)代”。除非我們這個(gè)行業(yè)發(fā)展到軟件的構(gòu)建方式和預(yù)測(cè)工

程項(xiàng)目相同，否則團(tuán)隊(duì)中有人一直跟隨技術(shù)的發(fā)展，有能力做出如何設(shè)計(jì)軟件的正確決策,

還是很重要的。換句話說(shuō)，軟件架構(gòu)師還需要扮演結(jié)構(gòu)工程師和建筑師的角色。

實(shí)現(xiàn)角色

最后，簡(jiǎn)要地說(shuō)一下，人們?nèi)绾螌?shí)現(xiàn)石匠大師的角色。下面這段話來(lái)自維基百科的“石匠

工藝”頁(yè)面14：

14http:〃/wiki/Stonemasonry

中世紀(jì)對(duì)石匠技能的需求很大，行業(yè)協(xié)會(huì)的成員按水平被劃分為三個(gè)等級(jí)：學(xué)徒、幫

工和石匠大師。學(xué)徒要和師傅簽訂契約，以此換取師傅的培訓(xùn)；幫工的技能要高一些,

可以到外面去協(xié)助別的師傅；石匠大師被看作自由人，可以按自己的意愿選擇主顧的

項(xiàng)目。

這反映了我自己擔(dān)任軟件架構(gòu)角色的經(jīng)驗(yàn)。它是一個(gè)漸進(jìn)的過(guò)程。像很多人一樣，我的職

業(yè)生涯始于在別人的監(jiān)督下寫代碼，漸漸地，當(dāng)我獲得更多的經(jīng)驗(yàn)，就開始承擔(dān)更大的設(shè)

計(jì)任務(wù)。不同于中世紀(jì)的建筑行業(yè)，對(duì)于如何從初級(jí)開發(fā)者到軟件架構(gòu)師，軟件開發(fā)行業(yè)

缺乏明確的路線。我們沒(méi)有普遍的學(xué)徒模式。

架構(gòu)師要和團(tuán)隊(duì)一起工作

對(duì)很多組織來(lái)說(shuō)，這里有個(gè)大問(wèn)題：找不到足夠的架構(gòu)師。雖然石匠大師可能沒(méi)有太多時(shí)

間自己去跟石頭打交道，但還是和團(tuán)隊(duì)一起工作。我常常遇到一些架構(gòu)師，他們要協(xié)助多

個(gè)不同團(tuán)隊(duì)。很明顯，如果和多個(gè)不同團(tuán)隊(duì)一起工作，要向軟件交付的實(shí)踐部分做出貢獻(xiàn)

是不現(xiàn)實(shí)的，你沒(méi)有時(shí)間寫任何代碼。

在多個(gè)團(tuán)隊(duì)中扮演軟件架構(gòu)角色，并不是一個(gè)有效的工作方式。通常這種情況發(fā)生時(shí)，都

有一個(gè)由被視為共享資源的架構(gòu)師組成的中心組（比如“企業(yè)架構(gòu)組"）。根據(jù)我所讀到的,

石匠大師任何時(shí)候都會(huì)只關(guān)注一個(gè)建筑工地，這也正是我們的軟件開發(fā)團(tuán)隊(duì)?wèi)?yīng)該采用的方

法。如果你認(rèn)為這不可能，就看看中世紀(jì)建筑行業(yè)是怎么解決這個(gè)問(wèn)題的15：

15http:〃www.historylearningsite.co.uk/medievalmasons.htm

每個(gè)石匠都會(huì)帶一個(gè)為他工作的學(xué)徒。當(dāng)石匠接下一份新工作，學(xué)徒也會(huì)跟著他。如

果石匠覺(jué)得自己的學(xué)徒已經(jīng)對(duì)行當(dāng)足夠了解，就會(huì)讓他在石匠行