通常,人們對軟件架構(gòu)師持兩種錯誤的看法。有人認為軟件架構(gòu)師是一種高高在上的職位;有人認為軟件架構(gòu)師完全不懂開發(fā),只是會畫條條框框的指揮家!冻绦騿T必讀之軟件架構(gòu)》將打破這些傳統(tǒng)的認知,模糊軟件開發(fā)和架構(gòu)在流程中的界限,進而為軟件架構(gòu)正名!冻绦騿T必讀之軟件架構(gòu)》是一本強調(diào)實踐、注重實效、輕量級、面向開發(fā)者的軟件架構(gòu)指南。
如果你是一名想成為軟件架構(gòu)師的程序員,那么《程序員必讀之軟件架構(gòu)》就是為你準備的。
架構(gòu)師真正要學會的事情
要學會去看,然后忘掉
有一本書叫《觀止》,寫的是微軟研發(fā)WindowsNT的一段故事!坝^止”在這里的意思是說“看到這些,就無需再看了”,因為世上之物亦無過于此。20多年過去,如今微軟在操作系統(tǒng)上面臨著的種種挑戰(zhàn)與困境,其實與《觀止》所敘的研發(fā)方法、理念與目標有著與生俱來的血緣關(guān)系。
另一個與“看”相關(guān)的詞匯是“所見即可得”(WYSIWYG)。這個詞以及與此相關(guān)的WIMP(Windows,Icon,MenuandPointer)曾經(jīng)主導了整個人機交互的設計理念。也是在20多年前,Borland為Windows桌面系統(tǒng)成功地設計了跨語言的VCL,由此“所見即所得”成為Borland對“如何更便捷地構(gòu)建UI”的基本假想,以至于這家偉大的公司在互聯(lián)網(wǎng)時代來臨時決定“用VCL描述界面的方式來解決‘網(wǎng)站設計’的問題(RadPHP)”。
然而,互聯(lián)網(wǎng)上的網(wǎng)頁是沒有WIMP的;移動設備上的操作系統(tǒng)也不再采用與WindowsNT類似的方式開發(fā)。
Borland在幾年之前將整個開發(fā)工具產(chǎn)品線都賣掉了。當時盛大的一個Delphi圈子發(fā)起了一次“緬懷活動”,組織者說:“愛民,你應該會為那個時代寫點什么吧?”
我在那個緬懷網(wǎng)頁上寫下了五個字:所見即所礙。
2.要學會去聽,然后忘掉
我通常說架構(gòu)是一種能力,架構(gòu)角色則是要求你在具體事務中行使某些行為,而架構(gòu)師則是用來標識這些能力與行為的一個職務。
當一些人將個人成長定義為“職業(yè)發(fā)展”時,就表現(xiàn)為“怎樣成為架構(gòu)師”這樣的問題。對此有三種解決方案,第一種是印一張寫著這樣頭銜的名片,而“是與不是”架構(gòu)師并不重要;第二種是直接否定這個職務的意義,比如聲稱敏捷天生就是反架構(gòu)的,于是“架構(gòu)師”變成了要打倒的對象,所以成不成為這個將被打倒的對象也就不重要了;第三種則干脆聲稱“人人都是架構(gòu)師”,既然人人都是了,那么“如何成為”也自然就不重要了。
我們大多數(shù)人都具有架構(gòu)的能力,并且也或多或少地行使某些架構(gòu)角色的行為,唯一缺乏的只是一個叫做“架構(gòu)師”的頭銜而已。問題出在我們總是期望別人通過這樣的頭銜來認可自己。于是我們?yōu)樽约嘿N上這樣或那樣的標簽,然后跟別人持有的同種標簽去比對,期求出現(xiàn)一致或找出某種差別。于是我們聽到種種聲音:某某某真的是/不是、像/不像架構(gòu)師;如果是架構(gòu)師,那么就要這樣那樣,以及怎樣怎樣;其實這個架構(gòu)、這樣的架構(gòu),或某種架構(gòu)應該怎么做;以及架構(gòu)是什么,架構(gòu)師是什么,等等;仡櫋叭N解決方案”,仍是困在這樣的認可求同之中,與之在做著種種斗爭罷了。
其實不單是你的所見阻礙了你自己,你還被別人的所見阻礙著。
3.要學會去做,然后忘掉
朋友跟我聊他家的兩歲小孩:我剛把桌子收拾好,一轉(zhuǎn)眼杯子碗筷什么的都全摔地上了。我問:“怎么了?”他說:“小孩子什么也不懂啊,她看到桌布覺得喜歡,就一把抓過去……”
小孩子沒能看到桌子上還有杯子,但正因為他們的視線里沒有杯子,他們的行動才簡單直接,才直達需求,才迅速。而我們的眼睛里有杯子、桌子、桌布等一切,我們經(jīng)年累月地維護著其中的次序與關(guān)系直到這些東西混成一體,然后我們便日日坐守在它們的面前,而又無覺他們的存在。
正是我們自己不知不覺地設定了這些事物之間的界線,并把這些界限、層次與邏輯井然的東西稱為“系統(tǒng)”。當我們從那些無序的事物中識別出了這樣的“系統(tǒng)”并用一些概念、名詞去定義了它們之后,我們對此的一切知識也就固化了。當這種秩序被建立起來之后,我們也就得到了對有序和無序(沒有你所設定的“這種秩序”)價值的識別與肯否;當我們設定了種種價值、觀念、觀察與系統(tǒng)的模型概念之后,也就完成了這個系統(tǒng)的架構(gòu)。
但這一過程,包括完成這一架構(gòu)——它可以命名為“世界觀”——的方法以及結(jié)果,在本質(zhì)上不過是讓你從一個格子跳到了另一個格子而已。我們處在種種界限之中,再也無法回到兩歲小孩的、一切無礙的視角:在那個視角下,根本就沒有所謂的界線。你之所以時時在尋求跨界,其實是源自你假設了“存在界線”,這就如同全棧的含義其實是“沒有棧”,而當有人信心滿滿地要“成為全棧工程師”時,他的眼里便又有個“這個!钡拇嬖凇
所謂跨界不是指你能力與方法上的變化,你的作為取決于你的格局,你的格局取決于你的所見。
4.要學會超越
架構(gòu)師需要超越自己與別人的所見,因為你觀察與架構(gòu)的對象稱為“系統(tǒng)”,你看到系統(tǒng)多少的真相,決定了你用怎樣的影像去表現(xiàn)它,并進而推進與實現(xiàn)這種影像,亦即是架構(gòu)。我們既已知道的、理解的、明白的,形成了我們的知識與行為的一切,卻也正是阻礙著我們前進的東西。這些障礙正是你以為你最珍視的、最不可放棄的、最鮮血淅瀝體驗過的那些經(jīng)驗與成就。在這些所得與所礙中掙扎與決策,就是架構(gòu)師的全部職責。因此作為架構(gòu)師,你需要能夠超越自已對系統(tǒng)的既有認識,看到你在光明中——顯而易見之處——所未見的,這是你驅(qū)動系統(tǒng)架構(gòu)進化的主要動力。
所以架構(gòu)中最難超越的并不是某個大師或前輩,而是你以及你為自己所作的設定。當你設定了“架構(gòu)師”這個目標,便設定了這個目標所表達的某種影像(角色),你最終可能變得跟這個影像完全一致——成為所謂的“真正的架構(gòu)師”,但你仍不過是困囿于對這個“角色”的一個假設/設定而已。唯一破局的方法是:超越別人對某個角色的定義,將自己做成這個角色。
至此,你是否還在這個角色之中,就是你的覺悟了。
周愛民
現(xiàn)任豌豆莢架構(gòu)師
前盛大網(wǎng)絡平臺架構(gòu)師、支付寶業(yè)務架構(gòu)師
SimonBrown,全球知名軟件架構(gòu)獨立咨詢師、講師,創(chuàng)辦了專門討論軟件架構(gòu)問題的網(wǎng)站“編碼架構(gòu)”(codingthearchitecture.com)。他自稱是寫代碼的軟件架構(gòu)師和明白架構(gòu)的軟件開發(fā)者。自2008年以來的7年時間里,Simon在全球28個國家做過有關(guān)軟件架構(gòu)、技術(shù)領導力及其與敏捷的平衡等主題的百余場演講,并于2012年8月在中國舉辦的ArchSummit全球架構(gòu)師峰會上以“郁悶的架構(gòu)師”和“如何設計安全的架構(gòu)”為主題發(fā)表演講,深受與會者好評。Simon已為全球20多個國家的軟件團隊提供咨詢和培訓,他的客戶既有小型技術(shù)初創(chuàng)企業(yè),也不乏全球家喻戶曉的品牌公司。
推薦序一:架構(gòu)師真正要學會的事情
推薦序二
譯者序2.0
序
關(guān)于本書
軟件架構(gòu)培訓
Part Ⅰ 什么是軟件架構(gòu)
第1章 什么是架構(gòu)
第2章 架構(gòu)的種類
第3章 軟件架構(gòu)是什么
第4章 敏捷軟件架構(gòu)是什么
第5章 架構(gòu)對上設計
第6章 軟件架構(gòu)重要嗎
第7章 問題
Part Ⅱ 軟件架構(gòu)的角色
第8章 軟件架構(gòu)的角色
第9章 軟件架構(gòu)師應該編碼嗎
第10章 軟件架構(gòu)師應該是建造大師
第11章 從開發(fā)者到架構(gòu)師
第12章 拓展T
第13章 軟技能
第14章 軟件架構(gòu)不是接力運動
第15章 軟件架構(gòu)要引入控制嗎
第16章 小心鴻溝
第17章 未來的軟件架構(gòu)師在哪里
第18章 每個人都是架構(gòu)師,除非他們有其他身份
第19章 軟件架構(gòu)咨詢師
第20章 問題
Part Ⅲ 設計軟件
第21章 架構(gòu)驅(qū)動力
第22章 質(zhì)量屬性(非功能需求)
第23章 處理非功能需求
第24章 約束
第25章 原則
第26章 技術(shù)不是實現(xiàn)細節(jié)
第27章 更多分層等于更高復雜度
第28章 協(xié)同設計是一把雙刃劍
第29章 軟件架構(gòu)是對話的平臺
第30章 SharePoint項目也需要軟件架構(gòu)
第31章 問題
Part Ⅳ 可視化軟件
第32章 溝通障礙
第33章 對草圖的需要
第34章 效的草圖
第35章 C4:語境、容器、組件和類
第36章 語境圖
第37章 容器圖
第38章 組件圖
第39章 是否包含技術(shù)選擇
第40章 你會那樣編碼嗎
第41章 軟件架構(gòu)和編碼
第42章 你不需要UML工具
第43章 有效的草圖
第44章 C4的常見問題
第45章 問題
Part Ⅴ 為軟件生成文檔
第46章 代碼不會講述完整的故事
第47章 軟件文檔即指南
第48章 語境
第49章 功能性概覽
第50章 質(zhì)量屬性
第51章 約束
第52章 原則
第53章 軟件架構(gòu)
第54章 外部接口
第55章 代碼
第56章 數(shù)據(jù)
第57章 基礎設施架構(gòu)
第58章 部署
第59章 運營和支持
第60章 決策日志
第61章 問題
Part Ⅵ 開發(fā)生命周期中的軟件架構(gòu)
第62章 敏捷和架構(gòu)的沖突:神話還是現(xiàn)實
第63章 量化風險
第64章 風險風暴
第65章 恰如其分的預先設計
第66章 初識軟件架構(gòu)
第67章 問題
Part Ⅶ 金融風險系統(tǒng)
第68章 金融風險系統(tǒng)
Part Ⅷ 附錄:"技術(shù)部落"的軟件指南