Simon Brown 是全球知名軟體架構獨立諮詢師、講師，創辦了專門討論軟體架構問題的網站“編碼架構”（CodingTheArchitecture.com）。他自稱是寫程式碼的軟體架構師和明白架構的軟體開發者。自2008年以來的7年時間裡，Simon在全球28個國家做過有關軟體架構、技術領導力及其與敏捷的平衡等主題的百餘場演講，並於2012年8月在中國舉辦的ArchSummit全球架構師峰會上以“鬱悶的架構師”和“如何設計安全的架構”為主題發表演講，深受與會者好評。Simon已為全球20多個國家的軟體團隊提供諮詢和培訓，他的客戶既有小型技術初創企業，也不乏全球家喻戶曉的品牌公司。Simon著有《程式設計師必讀之軟體架構》一書，他在這本書中打破傳統的認知，模糊軟體開發和架構在流程中的界限，進而為軟體架構正名。
架構師和開發者一樣，也經常寫程式碼，簡單的說，開發者和架構師之間最大的區別就是技術領導力。軟體架構師的角色需要理解最重要的架構驅動力是什麼，他提供的設計需要考慮這些因素。架構師還要控制技術風險，在需要的時候積極演化架構，並且負責技術質量保證。從根本上講，架構師是一個技術領導者的角色，這就是最大的區別。
問：一位開發者如何才能成為一位架構師？他/她需要掌握哪些領域之外的能力？
兩個字：經驗。我認識的大部分優秀軟體架構師同時也是出色的軟體開發者，他們都是經過時間逐漸發展成為架構師的。你需要有退後一步看程式碼的能力，從而理解特定軟體系統背後的設計決策。退後一步才能看到“大局”，這是架構師必須掌握的核心技能。這就是為什麼《程式設計師必讀之軟體架構》一書中加入了有關C4模型的內容，這是一種從多個不同抽象層面理解軟體系統的方法。這個方法有助於你退後一步反觀大局。
問：你對軟體架構的理解是否因為你的經歷和實踐而改變過？
是的。我對軟體架構的理解是根據我在諮詢公司工作時在各個專案中負責軟體架構的經驗形成的。諮詢是一件好事，尤其從最近我開始從事獨立諮詢師這個工作之後，我可以看到很多不同的團隊，不同的架構，不同的技術，以及人們不同的工作方式。世界各地的文化多樣性又為工作的複雜度增加了一個維度。無論是尋找特定問題解決方案的過程，還是為各種想法去蕪存菁的過程，這些經驗和與我共事的人的反饋一起最終形成了我今天對軟體架構的認識，這些思維也反應在了我的書中。
問：你書中的每一章內容都很有趣而且很精煉，有沒有想過寫幾本詳細論述《程式設計師必讀之軟體架構》中重要話題的書？
我寫作這本書的目的是要創造一本讓讀者可以從頭讀到尾的書，但是你也可以通過粗略瀏覽來找到具體問題的答案。對於這個問題來說，沒錯，有一些相關主題沒有出現在這本書中，這些主題可以構成一本與《程式設計師必讀之軟體架構》相互補的書。比如，圖表和建模的材料就可以擴充成一本完整的書，另外我和一個朋友也討論過要寫一本關於架構模式的技術性更強的書。
問：你在書中也談到了敏捷方法，你是如何看待現在流行的"敏捷已死"的說法的？
我聽過很多人說“敏捷已死”，他們觀點似乎來自兩個主要視角。首先，敏捷這個品牌現在雖然已經成為主流，但是其背後的一些意義卻在近些年消失殆盡。遵循敏捷實踐的軟體團隊有很多（比如每日站立會議，測試驅動開發等等）但是他們卻並不知道為什麼要遵照這些規則。盲目仿效敏捷實踐並不是敏捷的核心精神。
還有一些團隊，他們嘗試了敏捷，但是結果卻一團糟。我從軟體架構的視角特別能注意到這件事。大部分敏捷方法並不明確討論預先設計，而很多人把這點誤解為在敏捷專案中不需要做預先設計。當然，這不是事實，而現在人們開始尋找所謂的傳統開發和敏捷開發之間的平衡點。
敏捷並沒有死。採用敏捷方式意味著不斷地反思和調整你使用的方法，從而達到解決問題、變得更有效率或者更頻繁地交付優秀軟體的目的。團隊要如何完成這件事完全是由他們自己決定的。
問：作為技術領導者，如何協調一個大型專案中不同架構師的協同工作？
這是一個複雜的問題，根據背景的不同，答案也有很多。在我的經驗裡，大多數大型專案都包含有一些小團隊，可能是根據技術型別、子系統或元件區分的。在這種情況下，每個團隊一般都會有自己的軟體架構師，因為必須有人要為這些零散的部分負責。為了要管理整個專案，協調合作，有以下幾種方式：
1.一個單獨的架構師來管理整個專案，然後通過和基於團隊的架構師的合作來確保工作順利進行。
2.基於團隊的架構師共同協作，分享和執行架構領導者的角色。
3.某一位基於團隊的架構師額外花費一些時間來管理整個團隊。
第一種方式是我最不喜歡的，因為多出來的這個人可能不會像其他基於團隊的架構師那樣投身到每天的工作中，而且他有可能缺少必要的背景資訊，無法做出明智的決定。在第二種和第三種方式之間選擇的時候，我們可以根據基於團隊的架構師的領導力和興趣來決定。比如，強制一個不感興趣的人來管理整個專案可能不會成功。我個人比較傾向於第三種方式，但前提是其他基於專案的架構師也應該以某種程度參與進來，因為對整個專案的理解是必不可少的。
問：複雜是軟體架構的敵人，很多人欣賞那些已經用了十幾年的架構，但是這種情況下多場景預判會使得程式變得複雜。你是如何規劃架構時間點上的規模和設計的呢？
簡單的答案就是一開始就使用簡潔的設計，然後明確地思考模組化。軟體系統隨著時間很容易就會發展成“大泥球”，對於需求不斷變化的軟體系統來說，維護性和適應性的最大影響因素就是不同事物間的耦合程度。如果你從一開始就考慮了模組化，把軟體系統分解成高內聚低耦合的小模組單元，在未來你就可以更輕易地對系統做出改變。更進一步說，這意味著你定義的軟體架構應該反映在程式碼中。正如我在書中所說，事實並不永遠如此。我去年在一次大會中的演講（抱歉，演講是英文的而且在YouTube上）中深度講解了這個話題
問：你認為從10萬使用者擴充套件到1億使用者的架構存在嗎？如果存在的話，這些架構具有超強擴充套件性的原因是什麼？
我確定這樣的架構確實存在，但是在構造這些架構之初時，架構師可能並沒有設想到如此強的擴充套件能力。每個網際網路級別的大型網站背後的故事都很有趣，它們大多數都已經經歷過在開發、部署、運維的同時持續發展架構的階段。做出架構決策的關鍵就在於理解利弊和確定優先順序。你可以在CAP定理中看到類似的情況。一旦你明白了不能擁有一切，就會更容易做出架構決策了。
問：什麼樣的架構能夠做到快速響應頻繁變化的需求？
和之前的答案一樣，簡潔的設計和模組化會讓你可以快速響應快速變化的需求。如果你需要經常改變架構，但只想改變其中的一部分，為了防止為每個小變化重新部署整個系統，採用微服務架構是一個明智的選擇。
問：有沒有什麼事是架構師永遠都不應該做的？
有，軟體架構師永遠都不應該停止程式設計和停止學習！:-)
更多精彩文章請點選此處閱讀
[img=程式設計師,架構師]https://jf-bucket-public.oss-cn-qingdao.aliyuncs.com/jfperiodical/attached/image/20150206/-1374111964.jpg[/img]
架構師和開發者一樣，也經常寫程式碼，簡單的說，開發者和架構師之間最大的區別就是技術領導力。軟體架構師的角色需要理解最重要的架構驅動力是什麼，他提供的設計需要考慮這些因素。架構師還要控制技術風險，在需要的時候積極演化架構，並且負責技術質量保證。從根本上講，架構師是一個技術領導者的角色，這就是最大的區別。
問：一位開發者如何才能成為一位架構師？他/她需要掌握哪些領域之外的能力？
兩個字：經驗。我認識的大部分優秀軟體架構師同時也是出色的軟體開發者，他們都是經過時間逐漸發展成為架構師的。你需要有退後一步看程式碼的能力，從而理解特定軟體系統背後的設計決策。退後一步才能看到“大局”，這是架構師必須掌握的核心技能。這就是為什麼《程式設計師必讀之軟體架構》一書中加入了有關C4模型的內容，這是一種從多個不同抽象層面理解軟體系統的方法。這個方法有助於你退後一步反觀大局。
問：你對軟體架構的理解是否因為你的經歷和實踐而改變過？
是的。我對軟體架構的理解是根據我在諮詢公司工作時在各個專案中負責軟體架構的經驗形成的。諮詢是一件好事，尤其從最近我開始從事獨立諮詢師這個工作之後，我可以看到很多不同的團隊，不同的架構，不同的技術，以及人們不同的工作方式。世界各地的文化多樣性又為工作的複雜度增加了一個維度。無論是尋找特定問題解決方案的過程，還是為各種想法去蕪存菁的過程，這些經驗和與我共事的人的反饋一起最終形成了我今天對軟體架構的認識，這些思維也反應在了我的書中。
問：你書中的每一章內容都很有趣而且很精煉，有沒有想過寫幾本詳細論述《程式設計師必讀之軟體架構》中重要話題的書？
我寫作這本書的目的是要創造一本讓讀者可以從頭讀到尾的書，但是你也可以通過粗略瀏覽來找到具體問題的答案。對於這個問題來說，沒錯，有一些相關主題沒有出現在這本書中，這些主題可以構成一本與《程式設計師必讀之軟體架構》相互補的書。比如，圖表和建模的材料就可以擴充成一本完整的書，另外我和一個朋友也討論過要寫一本關於架構模式的技術性更強的書。
問：你在書中也談到了敏捷方法，你是如何看待現在流行的"敏捷已死"的說法的？
我聽過很多人說“敏捷已死”，他們觀點似乎來自兩個主要視角。首先，敏捷這個品牌現在雖然已經成為主流，但是其背後的一些意義卻在近些年消失殆盡。遵循敏捷實踐的軟體團隊有很多（比如每日站立會議，測試驅動開發等等）但是他們卻並不知道為什麼要遵照這些規則。盲目仿效敏捷實踐並不是敏捷的核心精神。
還有一些團隊，他們嘗試了敏捷，但是結果卻一團糟。我從軟體架構的視角特別能注意到這件事。大部分敏捷方法並不明確討論預先設計，而很多人把這點誤解為在敏捷專案中不需要做預先設計。當然，這不是事實，而現在人們開始尋找所謂的傳統開發和敏捷開發之間的平衡點。
敏捷並沒有死。採用敏捷方式意味著不斷地反思和調整你使用的方法，從而達到解決問題、變得更有效率或者更頻繁地交付優秀軟體的目的。團隊要如何完成這件事完全是由他們自己決定的。
問：作為技術領導者，如何協調一個大型專案中不同架構師的協同工作？
這是一個複雜的問題，根據背景的不同，答案也有很多。在我的經驗裡，大多數大型專案都包含有一些小團隊，可能是根據技術型別、子系統或元件區分的。在這種情況下，每個團隊一般都會有自己的軟體架構師，因為必須有人要為這些零散的部分負責。為了要管理整個專案，協調合作，有以下幾種方式：
1.一個單獨的架構師來管理整個專案，然後通過和基於團隊的架構師的合作來確保工作順利進行。
2.基於團隊的架構師共同協作，分享和執行架構領導者的角色。
3.某一位基於團隊的架構師額外花費一些時間來管理整個團隊。
第一種方式是我最不喜歡的，因為多出來的這個人可能不會像其他基於團隊的架構師那樣投身到每天的工作中，而且他有可能缺少必要的背景資訊，無法做出明智的決定。在第二種和第三種方式之間選擇的時候，我們可以根據基於團隊的架構師的領導力和興趣來決定。比如，強制一個不感興趣的人來管理整個專案可能不會成功。我個人比較傾向於第三種方式，但前提是其他基於專案的架構師也應該以某種程度參與進來，因為對整個專案的理解是必不可少的。
問：複雜是軟體架構的敵人，很多人欣賞那些已經用了十幾年的架構，但是這種情況下多場景預判會使得程式變得複雜。你是如何規劃架構時間點上的規模和設計的呢？
簡單的答案就是一開始就使用簡潔的設計，然後明確地思考模組化。軟體系統隨著時間很容易就會發展成“大泥球”，對於需求不斷變化的軟體系統來說，維護性和適應性的最大影響因素就是不同事物間的耦合程度。如果你從一開始就考慮了模組化，把軟體系統分解成高內聚低耦合的小模組單元，在未來你就可以更輕易地對系統做出改變。更進一步說，這意味著你定義的軟體架構應該反映在程式碼中。正如我在書中所說，事實並不永遠如此。我去年在一次大會中的演講（抱歉，演講是英文的而且在YouTube上）中深度講解了這個話題
問：你認為從10萬使用者擴充套件到1億使用者的架構存在嗎？如果存在的話，這些架構具有超強擴充套件性的原因是什麼？
我確定這樣的架構確實存在，但是在構造這些架構之初時，架構師可能並沒有設想到如此強的擴充套件能力。每個網際網路級別的大型網站背後的故事都很有趣，它們大多數都已經經歷過在開發、部署、運維的同時持續發展架構的階段。做出架構決策的關鍵就在於理解利弊和確定優先順序。你可以在CAP定理中看到類似的情況。一旦你明白了不能擁有一切，就會更容易做出架構決策了。
問：什麼樣的架構能夠做到快速響應頻繁變化的需求？
和之前的答案一樣，簡潔的設計和模組化會讓你可以快速響應快速變化的需求。如果你需要經常改變架構，但只想改變其中的一部分，為了防止為每個小變化重新部署整個系統，採用微服務架構是一個明智的選擇。
問：有沒有什麼事是架構師永遠都不應該做的？
有，軟體架構師永遠都不應該停止程式設計和停止學習！:-)
更多精彩文章請點選此處閱讀