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

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

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

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

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

　　問：你對軟件架構的理解是否因為你的經(jīng)歷和實踐而改變過？

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

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

　　Simon Brown：我寫作這本書的目的是要創(chuàng)造一本讓讀者可以從頭讀到尾的書，但是你也可以通過粗略瀏覽來找到具體問題的答案。對于這個問題來說，沒錯，有一些相關主題沒有出現(xiàn)在這本書中，這些主題可以構成一本與《程序員必讀之軟件架構》相互補的書。比如，圖表和建模的材料就可以擴充成一本完整的書，另外我和一個朋友也討論過要寫一本關于架構模式的技術性更強的書。

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

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

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

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

　　問：作為技術領導者，如何協(xié)調(diào)一個大型項目中不同架構師的協(xié)同工作？

　　Simon Brown：這是一個復雜的問題，根據(jù)背景的不同，答案也有很多。在我的經(jīng)驗里，大多數(shù)大型項目都包含有一些小團隊，可能是根據(jù)技術類型、子系統(tǒng)或組件區(qū)分的。在這種情況下，每個團隊一般都會有自己的軟件架構師，因為必須有人要為這些零散的部分負責。為了要管理整個項目，協(xié)調(diào)合作，有以下幾種方式：

　　一個單獨的架構師來管理整個項目，然后通過和基于團隊的架構師的合作來確保工作順利進行。

　　基于團隊的架構師共同協(xié)作，分享和執(zhí)行架構領導者的角色。

　　某一位基于團隊的架構師額外花費一些時間來管理整個團隊。

　　第一種方式是我最不喜歡的，因為多出來的這個人可能不會像其他基于團隊的架構師那樣投身到每天的工作中，而且他有可能缺少必要的背景信息，無法做出明智的決定。在第二種和第三種方式之間選擇的時候，我們可以根據(jù)基于團隊的架構師的領導力和興趣來決定。比如，強制一個不感興趣的人來管理整個項目可能不會成功。我個人比較傾向于第三種方式，但前提是其他基于項目的架構師也應該以某種程度參與進來，因為對整個項目的理解是必不可少的。

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

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

　　問：你認為從10萬用戶擴展到1億用戶的架構存在嗎？如果存在的話，這些架構具有超強擴展性的原因是什么？

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

　　問：什么樣的架構能夠做到快速響應頻繁變化的需求？

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

　　問：有沒有什么事是架構師永遠都不應該做的？

　　Simon Brown：有，軟件架構師永遠都不應該停止編程和停止學習！