你是個軟體架構師嗎？

=========================================================

本文為轉載，轉載必須確保本文完整並完整保留原作者資訊和本文連結

E-mail: khler@163.com

QQ:     23381103

MSN:   pragmac@hotmail.com

原文：http://www.infoq.com/cn/articles/brown-are-you-a-software-architect

申明：轉載只為傳播知識，讓更多人享受作者智慧的結晶！

如原作者有異議，請立即聯絡本人，本人將在第一時間刪除，並深表歉意！

=========================================================

編者按： 本文作者 Simon Brown ，在三月的QCon London上發表了同樣主題的演講《Software Architecture for Developers》。

經常被用來區分軟體架構和軟體設計開發的關鍵幾點包括 伸縮性和抽象程度的增加以及作出正確設計決策意義的增強。軟體架構是通過一個全域的觀點，宏觀的視角來理解軟體系統作為一個整體如何工作。開發和架構的界限難以捉摸。有些人告訴你它根本不存在，架構只是開發人員們所做的設計過程的簡單擴充。 另外一些人認為這是一個鴻溝，它只能由那些做到高度抽象，而且不會陷入實現細節的開發人員才能跨越。通常，在這兩個極端的觀點中間某處有個可操作的平衡點；不論如何，怎麼從開發轉換為架構師都是個有趣的問題。

即使這能夠協助區分軟體開發和架構，它並不能協助理解某人如何從開發提升到架構。 並且，它也不能協助識別誰能夠成為一個好的軟體架構師，如果你想僱人的話你如何去尋找他們以及你是否是一個軟體架構師。

經驗可以判定但你需要更深入地瞭解

要成為一個軟體架構師並不是一夜之間或者一個職位的提升就能簡單達到的。 這是個職責，而不是頭銜。這是個進化的過程，你將會逐步得到擔當這個職責所需的經驗和信心。

當你尋找架構師時，需要考慮各方面的素質，他們過去的經驗往往是他們有能力擔當這個職責很好的判斷。由於軟體架構師的職責是多種多樣的，所以你需要再深入瞭解他們在不同領域的參與度，影響力，領導力和責任感。一般來說，在大多數項目中軟體架構可分為兩個階段，架構的定義，然後是它的交付。

軟體架構的定義

架構的定義過程看起來非常簡單明了。 你需要做的是理解需求並設計一個系統來滿足需求。 但實際上並沒有那麼簡單，根據你不同的做法，軟體架構的職責之間差距很大，以及如何認真看待自己的職責而定。如所示，這個職責的架構定義部分，可以進一步細分成不同的元素。

1. 管理非功能性需求：軟體項目經常陷入問使用者要求是什麼，什麼是他們想要的功能，但很少問他們需要什麼非功能性需求（或系統品質）有時候，干係人會告訴我們，“這個系統必須很快”，但是這太主觀了。非功能性需求如果要滿足的話需要明確，可度量，可獲得以及可測試。大多數非功能性需求本質上是技術層面的而且經常對軟體架構有很大的影響。理解非功能性要求是架構師職責非常重要的一個部分，但假設這些需求是什麼並不一定是對他們的挑戰。你見過多少系統真正需要24x7的運行呢？

2. 架構定義：捕捉到了非功能性需求後，下一步是開始思考你打算如何去解決干係人提出的這些問題並定義它的架構。 公平的說每個軟體系統都有一個架構，但並不是每個軟體系統都有一個定義好的架構。這正是問題的關鍵。架構定義過程讓你想清楚你打算怎麼在兼顧需求和限制的情況下把問題解決好。架構定義是將結構，方針，原則和領導力引入軟體項目的技術層面。定義架構是作為軟體架構師的工作，但是從頭開始設計一個軟體系統和對已存在的系統擴充是相當不同的。
3. 技術選型：技術選型通常是一個有趣的練習，但它也有公平的挑戰,因為你需要綜合考慮成本、許可、供應商關係、技術策略、相容性、協作性、支援、部署、升級的政策以及終端使用者環境等各方面。綜合這些因素，通常會導致簡單選擇類似富用戶端技術而進入了完全的噩夢。接下來的問題就是這些技術是否能真正有用。技術選型是徹頭徹尾的風險管理；複雜性或不確定性太高的時候要減輕風險，當有機會或利益的時候要引入風險。技術決策需要考慮多種因素，而且所有的技術決策需要被檢查和評估。這包含軟體項目的主要組成部分乃至開發中引入的類庫和架構。如果定義一個架構，你還需要有信心認為選擇這項技術是正確的。同樣在技術評估中也還是存在開發新系統和向現有的系統增加新技術的不同點。
4. 架構評估：如果你設計軟體，你需要問問自己你的架構是否有用。 對我來說，一個架構是成功的，如果它滿足非功能性需求，而且為其他部分的代碼提供必要的基礎，並為解決和存在的業務問題提供足夠的平台。軟體的一個最大的問題就是它複雜而抽象，導致很難從UML圖或代碼本身去設想出運行時的特性。在軟體開發週期中我們進行了很多不同類型的測試，這樣我們能夠有信心我們發布的系統在推出時能夠正常運行。我們為什麼不對架構也這樣做呢？ 如果能夠測試你的架構，那你就可以證明它是有效。如果你能儘早做到這一點，你就能減少項目失敗的風險，而不是簡單地希望一切都好。
5. 架構協作：任何一個軟體都不是與世隔絕的，需要很多人理解它。 包括從需要理解和切入架構的直接Team Dev到其他對安全性、資料庫、運營、維護、支援等有興趣的干係人。要想讓一個軟體項目成功，你需要和所有的系統干係人緊密協作來保證架構和所在的環境很好的整合。不幸的是，現狀是與Team Dev的架構協作很少發生，更不要說外部干係人了。

軟體架構的發布

對於架構的發布也是同樣，對於成功的軟體項目參與程度的不同，也決定了軟體架構職責的不同。

1. 擁有全域的視角：為了把一個架構成功地實現，我們需要具有全域的視角並把貫穿軟體開發生命週期的願景加以宣傳與推廣，必要的話在整個項目中展開和完善，並對成功發布負責。如果如果你定義了一個架構，參與並保持不斷髮展的架構才是有意義的，而不是選擇把它傳遞給一個“執行小組”。

2. 領導力：擁有全域的視角是技術領導的一個方面，但是還有其他事情在軟體項目發布階段需要做。 這包括承擔責任、提供技術指導、作出技術決策以及具有權力作出這些決定。作為架構師，你需要進行技術領導來確保每件事都被考慮到，而且團隊在朝著正確的方向持續前進。軟體架構師職位是需要內在領導力的，雖然這聽起來很明顯，但很多項目團隊並沒有獲得他們所需要的技術領導，因為架構師認為一個成功的發布並不一定是他們所關注的問題。
3. 教練和指導：在大多數軟體開發項目中，教練和指導經常不被重視，團隊成員得不到他們需要的支援。 雖然技術領導是引導整個項目，但個人也經常需要協助。除此以外，教練和指導提供了一個強化技能的方式，並協助提升職業生涯。這應該是軟體架構師份內的事，而且指導團隊架構和設計與幫他們解決代碼問題是截然不同的。
4. 品質保證：即使是世界上最好的架構和領導，很糟糕的交付也足以讓一個具備其他成功條件的項目失敗。品質保證在架構師職責中占很大一部分，但這並不只是簡單做代碼檢查。 比如，你需要一個基準來確保，這意味著引入新的標準和工作實踐。從一個軟體開發的角度來說，這可能包括代碼標準、設計原則和源碼分析工具甚至於使用持續整合,自動化單元測試以及代碼覆蓋工具。可以說大多數項目品質保證做的並不夠，所以你需要搞清楚什麼是重要的並給予它足夠的保證。對於我來說，一個項目的重要部分包括架構上的重點，關鍵、複雜或高度可見的業務。你要關注實效並認識到你並不能保證一切，要知道做總比不做好。
5. 設計、開發與測試：軟體架構師的職責範圍的最後一件事是設計、開發與測試。作為一個實際動手的架構師並不是需要你每天都要寫代碼，但是它的確意味著你一直在參與項目，而且積極協助打造和交付它。說了這麼多，為什麼每天寫代碼不應該成為一個架構師職責的一部分呢？大多數架構師都有寫代碼的經驗，因此讓這些技能保鮮是有意義的。而且，架構師能體會到團隊裡其他人的痛苦和感受，這樣能讓他們更好地理解他們的架構從開發角度看是什麼樣的。很多公司有政策阻止軟體架構師從事寫代碼，因為架構師“去做那些廉價的工作太貴了” ，這顯然是個錯誤的態度...如果架構師已經花了那麼多時間精力為項目做架構，何必從政策上不允許他們多走一步來協助項目達到最終的成功呢？當然，有些情況下捲入代碼層級並不現實。比如，一個大的項目通常意味有一個更大的“全域觀” 來考慮它，而且可能有時候你就是沒有時間。但一般來說，一個寫代碼的架構師比只在旁邊觀望要更高效和快樂。

你是一個軟體架構師嗎？

不管你認為軟體開發和架構之間的界限只是一個幻覺還是個巨大的鴻溝，以上強調了人們對整個軟體架構中的經驗水平往往有很大的差別，而這取決於他們怎麼樣工作以及他們如何認真地看待他們的職責。大多數開發人員不是在某一個星期一的早晨醒來就宣布自己成為一個軟體架構師的。我當然也不是，我成為軟體架構師的路線是一個漸進的過程。話雖如此，但很可能同樣那些開發人員已經做了一部分架構的工作，不論他們的職位名稱是什麼。

為軟體系統的架構作出貢獻和自己負責定義它有很大的區別，擁有持續的、跨不同領域的技能、知識和經驗構成了軟體架構的職責。跨越軟體開發人員和架構師的界限取決於你自己，但是首先你要明白你的經驗水平，才能開始架構師之旅的第一站。

關於作者

你可以認為Simon Brown是一個寫代碼的軟體架構師或者理解架構的軟體開發人員。當他沒有用.NET或Java開發軟體的時候，Simon通常在做諮詢，指導或者培訓。 Simon還寫過關於Java的書，在行業活動做過演講，並且整合了一個叫Software Architecture for Developers的培訓課程， 該課程基於他在Coding the Architecture描 述的軟體架構。你可以通過e-mail 或Twitter 找到他。

查看英文原文：Are You a Software Architect?

 

宋體;color:black;mso-font-kerning:0pt'>