摘要：從根本上講，架構(gòu)師是一個(gè)技術(shù)領(lǐng)導(dǎo)者的角色，這就是最大的區(qū)別。對(duì)于這個(gè)問(wèn)題來(lái)說(shuō)，沒(méi)錯(cuò)，有一些相關(guān)主題沒(méi)有出現(xiàn)在這本書中，這些主題可以構(gòu)成一本與程序員必讀之軟件架構(gòu)相互補(bǔ)的書。我從軟件架構(gòu)的視角特別能注意到這件事。

  
非商業(yè)轉(zhuǎn)載請(qǐng)注明作譯者、出處，并保留本文的原始鏈接：http://www.ituring.com.cn/article/178034

Simon Brown 是全球知名軟件架構(gòu)獨(dú)立咨詢師、講師，創(chuàng)辦了專門討論軟件架構(gòu)問(wèn)題的網(wǎng)站“編碼架構(gòu)” （CodingTheArchitecture.com）。他自稱是寫代碼的軟件架構(gòu)師和明白架構(gòu)的軟件開發(fā)者。自2008年以來(lái)的7年時(shí)間里，Simon在全球28個(gè)國(guó)家做過(guò)有關(guān)軟件架構(gòu)、技術(shù)領(lǐng)導(dǎo)力及其與敏捷的平衡等主題的百余場(chǎng)演講，并于2012年8月在中國(guó)舉辦的ArchSummit全球架構(gòu)師峰會(huì)上以“郁悶的架構(gòu)師”和“如何設(shè)計(jì)安全的架構(gòu)”為主題發(fā)表演講，深受與會(huì)者好評(píng)。Simon已為全球20多個(gè)國(guó)家的軟件團(tuán)隊(duì)提供咨詢和培訓(xùn)，他的客戶既有小型技術(shù)初創(chuàng)企業(yè)，也不乏全球家喻戶曉的品牌公司。Simon著有《程序員必讀之軟件架構(gòu)》一書，他在這本書中打破傳統(tǒng)的認(rèn)知，模糊軟件開發(fā)和架構(gòu)在流程中的界限，進(jìn)而為軟件架構(gòu)正名。

問(wèn)：開發(fā)者和架構(gòu)師之間最大的區(qū)別是什么？

架構(gòu)師和開發(fā)者一樣，也經(jīng)常寫代碼，簡(jiǎn)單的說(shuō)，開發(fā)者和架構(gòu)師之間最大的區(qū)別就是技術(shù)領(lǐng)導(dǎo)力。軟件架構(gòu)師的角色需要理解最重要的架構(gòu)驅(qū)動(dòng)力是什么，他提供的設(shè)計(jì)需要考慮這些因素。架構(gòu)師還要控制技術(shù)風(fēng)險(xiǎn)，在需要的時(shí)候積極演化架構(gòu)，并且負(fù)責(zé)技術(shù)質(zhì)量保證。從根本上講，架構(gòu)師是一個(gè)技術(shù)領(lǐng)導(dǎo)者的角色，這就是最大的區(qū)別。

問(wèn)：一位開發(fā)者如何才能成為一位架構(gòu)師？他/她需要掌握哪些領(lǐng)域之外的能力？

兩個(gè)字：經(jīng)驗(yàn)。我認(rèn)識(shí)的大部分優(yōu)秀軟件架構(gòu)師同時(shí)也是出色的軟件開發(fā)者，他們都是經(jīng)過(guò)時(shí)間逐漸發(fā)展成為架構(gòu)師的。你需要有退后一步看代碼的能力，從而理解特定軟件系統(tǒng)背后的設(shè)計(jì)決策。退后一步才能看到“大局”，這是架構(gòu)師必須掌握的核心技能。這就是為什么《程序員必讀之軟件架構(gòu)》一書中加入了有關(guān)C4模型的內(nèi)容，這是一種從多個(gè)不同抽象層面理解軟件系統(tǒng)的方法。這個(gè)方法有助于你退后一步反觀大局。

問(wèn)：你對(duì)軟件架構(gòu)的理解是否因?yàn)槟愕慕?jīng)歷和實(shí)踐而改變過(guò)？

是的。我對(duì)軟件架構(gòu)的理解是根據(jù)我在咨詢公司工作時(shí)在各個(gè)項(xiàng)目中負(fù)責(zé)軟件架構(gòu)的經(jīng)驗(yàn)形成的。咨詢是一件好事，尤其從最近我開始從事獨(dú)立咨詢師這個(gè)工作之后，我可以看到很多不同的團(tuán)隊(duì)，不同的架構(gòu)，不同的技術(shù)，以及人們不同的工作方式。世界各地的文化多樣性又為工作的復(fù)雜度增加了一個(gè)維度。無(wú)論是尋找特定問(wèn)題解決方案的過(guò)程，還是為各種想法去蕪存菁的過(guò)程，這些經(jīng)驗(yàn)和與我共事的人的反饋一起最終形成了我今天對(duì)軟件架構(gòu)的認(rèn)識(shí)，這些思維也反應(yīng)在了我的書中。

問(wèn)：你書中的每一章內(nèi)容都很有趣而且很精煉，有沒(méi)有想過(guò)寫幾本詳細(xì)論述《程序員必讀之軟件架構(gòu)》中重要話題的書？

我寫作這本書的目的是要?jiǎng)?chuàng)造一本讓讀者可以從頭讀到尾的書，但是你也可以通過(guò)粗略瀏覽來(lái)找到具體問(wèn)題的答案。對(duì)于這個(gè)問(wèn)題來(lái)說(shuō)，沒(méi)錯(cuò)，有一些相關(guān)主題沒(méi)有出現(xiàn)在這本書中，這些主題可以構(gòu)成一本與《程序員必讀之軟件架構(gòu)》相互補(bǔ)的書。比如，圖表和建模的材料就可以擴(kuò)充成一本完整的書，另外我和一個(gè)朋友也討論過(guò)要寫一本關(guān)于架構(gòu)模式的技術(shù)性更強(qiáng)的書。

問(wèn)：你在書中也談到了敏捷方法，你是如何看待現(xiàn)在流行的"敏捷已死"的說(shuō)法的？

我聽過(guò)很多人說(shuō)“敏捷已死”，他們觀點(diǎn)似乎來(lái)自兩個(gè)主要視角。首先，敏捷這個(gè)品牌現(xiàn)在雖然已經(jīng)成為主流，但是其背后的一些意義卻在近些年消失殆盡。遵循敏捷實(shí)踐的軟件團(tuán)隊(duì)有很多（比如每日站立會(huì)議，測(cè)試驅(qū)動(dòng)開發(fā)等等）但是他們卻并不知道為什么要遵照這些規(guī)則。盲目仿效敏捷實(shí)踐并不是敏捷的核心精神。

還有一些團(tuán)隊(duì)，他們嘗試了敏捷，但是結(jié)果卻一團(tuán)糟。我從軟件架構(gòu)的視角特別能注意到這件事。大部分敏捷方法并不明確討論預(yù)先設(shè)計(jì)，而很多人把這點(diǎn)誤解為在敏捷項(xiàng)目中不需要做預(yù)先設(shè)計(jì)。當(dāng)然，這不是事實(shí)，而現(xiàn)在人們開始尋找所謂的傳統(tǒng)開發(fā)和敏捷開發(fā)之間的平衡點(diǎn)。

敏捷并沒(méi)有死。采用敏捷方式意味著不斷地反思和調(diào)整你使用的方法，從而達(dá)到解決問(wèn)題、變得更有效率或者更頻繁地交付優(yōu)秀軟件的目的。團(tuán)隊(duì)要如何完成這件事完全是由他們自己決定的。

問(wèn)：作為技術(shù)領(lǐng)導(dǎo)者，如何協(xié)調(diào)一個(gè)大型項(xiàng)目中不同架構(gòu)師的協(xié)同工作？

這是一個(gè)復(fù)雜的問(wèn)題，根據(jù)背景的不同，答案也有很多。在我的經(jīng)驗(yàn)里，大多數(shù)大型項(xiàng)目都包含有一些小團(tuán)隊(duì)，可能是根據(jù)技術(shù)類型、子系統(tǒng)或組件區(qū)分的。在這種情況下，每個(gè)團(tuán)隊(duì)一般都會(huì)有自己的軟件架構(gòu)師，因?yàn)楸仨氂腥艘獮檫@些零散的部分負(fù)責(zé)。為了要管理整個(gè)項(xiàng)目，協(xié)調(diào)合作，有以下幾種方式：

一個(gè)多帶帶的架構(gòu)師來(lái)管理整個(gè)項(xiàng)目，然后通過(guò)和基于團(tuán)隊(duì)的架構(gòu)師的合作來(lái)確保工作順利進(jìn)行。

基于團(tuán)隊(duì)的架構(gòu)師共同協(xié)作，分享和執(zhí)行架構(gòu)領(lǐng)導(dǎo)者的角色。

某一位基于團(tuán)隊(duì)的架構(gòu)師額外花費(fèi)一些時(shí)間來(lái)管理整個(gè)團(tuán)隊(duì)。

第一種方式是我最不喜歡的，因?yàn)槎喑鰜?lái)的這個(gè)人可能不會(huì)像其他基于團(tuán)隊(duì)的架構(gòu)師那樣投身到每天的工作中，而且他有可能缺少必要的背景信息，無(wú)法做出明智的決定。在第二種和第三種方式之間選擇的時(shí)候，我們可以根據(jù)基于團(tuán)隊(duì)的架構(gòu)師的領(lǐng)導(dǎo)力和興趣來(lái)決定。比如，強(qiáng)制一個(gè)不感興趣的人來(lái)管理整個(gè)項(xiàng)目可能不會(huì)成功。我個(gè)人比較傾向于第三種方式，但前提是其他基于項(xiàng)目的架構(gòu)師也應(yīng)該以某種程度參與進(jìn)來(lái)，因?yàn)閷?duì)整個(gè)項(xiàng)目的理解是必不可少的。

問(wèn)：復(fù)雜是軟件架構(gòu)的敵人，很多人欣賞那些已經(jīng)用了十幾年的架構(gòu)，但是這種情況下多場(chǎng)景預(yù)判會(huì)使得程序變得復(fù)雜。你是如何規(guī)劃架構(gòu)時(shí)間點(diǎn)上的規(guī)模和設(shè)計(jì)的呢？

簡(jiǎn)單的答案就是一開始就使用簡(jiǎn)潔的設(shè)計(jì)，然后明確地思考模塊化。軟件系統(tǒng)隨著時(shí)間很容易就會(huì)發(fā)展成“大泥球”，對(duì)于需求不斷變化的軟件系統(tǒng)來(lái)說(shuō)，維護(hù)性和適應(yīng)性的最大影響因素就是不同事物間的耦合程度。如果你從一開始就考慮了模塊化，把軟件系統(tǒng)分解成高內(nèi)聚低耦合的小模塊單元，在未來(lái)你就可以更輕易地對(duì)系統(tǒng)做出改變。更進(jìn)一步說(shuō)，這意味著你定義的軟件架構(gòu)應(yīng)該反映在代碼中。正如我在書中所說(shuō)，事實(shí)并不永遠(yuǎn)如此。我去年在一次大會(huì)中的演講（抱歉，演講是英文的而且在YouTube上）中深度講解了這個(gè)話題->https://www.youtube.com/watch?v=ehH3UGdSwPo

問(wèn)：你認(rèn)為從10萬(wàn)用戶擴(kuò)展到1億用戶的架構(gòu)存在嗎？如果存在的話，這些架構(gòu)具有超強(qiáng)擴(kuò)展性的原因是什么？

我確定這樣的架構(gòu)確實(shí)存在，但是在構(gòu)造這些架構(gòu)之初時(shí)，架構(gòu)師可能并沒(méi)有設(shè)想到如此強(qiáng)的擴(kuò)展能力。每個(gè)互聯(lián)網(wǎng)級(jí)別的大型網(wǎng)站背后的故事都很有趣，它們大多數(shù)都已經(jīng)經(jīng)歷過(guò)在開發(fā)、部署、運(yùn)維的同時(shí)持續(xù)發(fā)展架構(gòu)的階段。做出架構(gòu)決策的關(guān)鍵就在于理解利弊和確定優(yōu)先級(jí)。你可以在CAP定理中看到類似的情況。一旦你明白了不能擁有一切，就會(huì)更容易做出架構(gòu)決策了。

問(wèn)：什么樣的架構(gòu)能夠做到快速響應(yīng)頻繁變化的需求？

和之前的答案一樣，簡(jiǎn)潔的設(shè)計(jì)和模塊化會(huì)讓你可以快速響應(yīng)快速變化的需求。如果你需要經(jīng)常改變架構(gòu)，但只想改變其中的一部分，為了防止為每個(gè)小變化重新部署整個(gè)系統(tǒng)，采用微服務(wù)架構(gòu)是一個(gè)明智的選擇。

問(wèn)：有沒(méi)有什么事是架構(gòu)師永遠(yuǎn)都不應(yīng)該做的？

有，軟件架構(gòu)師永遠(yuǎn)都不應(yīng)該停止編程和停止學(xué)習(xí)！:-)