開發人員如何成爲架構師

不少架構師都是從好的開發人員逐步過渡而來的，但並不是每一個好的開發人員都但願成爲架構師，並且他們並非都適合作架構師。不管您是打算進行職業轉型的開發人員，仍是尋找能承擔體系結構設計責任的合適人選的經理，都務必對此轉型過程有個清楚的瞭解。本文將討論從實現專家到架構師的過渡過程。

　在尋找優秀的指揮的時候，您首先要找的是一名優秀的音樂演奏家。但並不是每一個音樂演奏家都能成爲優秀的指揮。架構師的專業發展方面也與此相似。愈來愈多的 IT 組織開始認識到良好軟件體系結構的重要性，架構師職業正迅速發展爲 IT 內一個獨立的門類。因爲要從至關小的候選範圍內招募架構師，所以這就給管理帶來了一些新挑戰。即便人力資源部門找到了候選者，針對經驗進行的篩選也比其餘門類更爲嚴格。跨越這些障礙的最快方式是要認識到，大部分好的架構師同時也是好的開發人員，所以尋找架構師人才時可能首先應該從普通開發人員中找起。招聘人員在對候選者（內部或外部）進行詳細審查時，應該考慮這個觀點。不過，對此資源進行挑選可能比較麻煩，由於只有極少的優秀開發人員具備成爲架構師的特徵或願望。

本文列出了開發人員成爲架構師要進行的工做。我將從可能考慮進行此轉型的開發人員和評估進行此轉型的開發人員的經理這兩個方面來探討這一問題。我還將提供一系列在作出這些決策時要考慮的因素。

我的特徵

軟件開發團隊和管理層之間的聯繫始終是 IT 中的一個關鍵所在。兩者都傾向於以徹底不一樣的方式考慮給定的問題。大部分相關技術都是討論項目經理應如何跟蹤和解釋開發人員的進度和問題。但溝通不足的狀況仍然很是廣泛，並且這是項目失敗的首要緣由。好的架構師是解決這個問題的最有效辦法。架構師的主要責任是提供開發人員和項目經理之間的共用溝通媒體。他們負責讓業務規則及需求與工程實踐及限制相適應，以確保成功。如下是成功架構師的一些主要特徵。

願意並有能力進行溝通：在開發人員中發現架構師的最有價值標準是有效的溝通。您須要技術嫺熟、經驗豐富的開發人員，這樣的人員須要有就項目中的業務相關問題進行溝通的經歷。架構師常常必須對理解方面的差距進行預計，而後纔能有所貢獻。他們必須願意克服困難來確保技術和業務觀點的融合。他們並沒必要對意見交換工做進行計劃和協調；這仍然主要是項目經理的工做。他們的任務是肯定表述系統設計時的最佳工具和構件，以促進有效的意見交換。他們必須可以判斷當前方法顯得不足而須要採用新方法的狀況。寫做技能也很是重要，還須要具備製做草圖的技能或使用製圖軟件的能力。

具備處理談判細節方面的經驗：架構師常常須要負責討論系統開發的技術折衷方案。優先級的衝突可能會帶來實踐限制、風險規避或可能致使在各個不一樣業務組之間需求不一樣。優秀的架構師可以有效地評估技術可能性，並能在不損失項目的主要價值的前提下制訂開發計劃來處理各類利害關係和限制。這與前面討論的溝通技能緊密相關，但同時也要體現架構師的技術能力。好的架構師候選者應該是常常幫助對有爭議的討論進行引導的人，可以使討論得出新的想法，而不會使其在一個位置停滯不前。

自覺主動；積極解決設計問題：架構師的平常工做目標常常並不明確。不少開發人員直接參考功能規範來列出任務清單。架構師一般則是向這些開發人員提供所需結構的人員，以便儘量提升工做效率。好的候選者不只進行溝通方面的工做，並且也會預計各類設計問題並加以解決——一般在沒有任何具體指示的狀況下自覺進行。不管所分配的職責如何，積極參與項目的開發人員都有機會從一塊兒工做的人員中脫穎而出。

抽象思惟和分析：架構師必須可以理解表述模糊的概念並將其變成相關各方可以理解的項目構件。他們必須可以理解抽象概念，並以具體的語言對其進行溝通。開發人員中好的候選者常常要求或本身主動解釋開發生命週期中容易混淆的問題。他們能迅速評估各類想法並將其歸入後續工做的操做建議中。

開發人員常常具備很強的數學能力，而好的架構師則傾向於表現出更強的口頭表達能力。管理人員常常說開發人員具備「工程意識」，而這是一個用於評估架構師的很是有意義的方面。架構師應該具備很強的解決技術問題的能力，但還必須可以準確獲知更爲全面的人員如何與技術交互的信息。這要求具備某種形式的抽象思惟（而再也不是代碼的細節），這種思惟能力可能較難造成。

有些人認爲，某種級別的正式教育是成爲優秀開發人員的必備條件之一，我並不一樣意這種精英論。我遇到了不少高中就輟學的優秀開發人員。不過，對於體系結構設計工做，個人我的經驗以及我對所需能力的認識都讓我相信，好的架構師一般至少得到了一個有挑戰性的學士學位。

跟蹤生命週期

好的架構師一般有在具有定義良好的軟件開發生命週期（Software Development Life Cycle，SDLC）的組織工做的經驗。架構師必須理解在其所屬專業內最重要的操做過程。這並不意味着須要有其餘前提，例如，並不須要高能力成熟度模型（Capability Maturity Model，CMM）級別的工做經驗。好的架構師可能來自使用 SDLC 的多個小型迭代的極限編程（Extreme Programming，XP）方法的組織。務必注意各類傳統軟件開發操做，如 Michael A. Jackson 的方法：Jackson 結構編程（Jackson Structured Programming，JSP）和 Jackson 系統開發（Jackson System Development，JSD）（請參見參考資料）。Jackson 的研究對架構師職業發展的意義就像 Donald Knuth 的研究對程序員同樣重要。架構師能夠偏心任何經典的、通過時間考驗的軟件系統開發方法。

SDLC 也能夠成爲評估架構師合適人選的有用機制。每一個 SDLC 階段都具備能提供相關線索的特徵。SDLC 包含不少小的變體，但在此部分，我將使用幾乎全部方法的公共基礎部分。下面的列表詳細說明了 SDLC 的各個階段，並列出了好的架構師候選者在每一個階段表現出來的特徵。

分析：在分析期間，好的架構師會考慮非技術影響，以便了解需求和將在其中進行開發的環境。架構師可爲風險評估任務帶來普遍的軟件經驗供參考。尋找具備豐富經驗的開發人員，以幫助業務部門理解技術人員正確解釋需求所需的信息。尋找在開發的早期階段可以預計可能遇到的問題的開發人員。

設計：在高級設計期間，好的架構師會收集問題空間的各個抽象元素，並就其進行溝通，以便開發團隊草擬將要開發的系統的相關圖表。架構師負責將需求謹慎地映射到所獲得的系統體系結構的功能。在詳細設計期間，他們所扮演的角色並非核心角色，但爲了根據整個系統的規則對特定模塊的元素進行審查，仍然須要他們。尋找善於讓團隊可以預計設計決策對最終系統的影響的開發人員。尋找善於肯定一些最佳構件來促進與技術和非技術受衆溝通設計問題的開發人員。

實現：在實現期間，架構師對項目進行引導，以確保其符合系統體系結構。他們在一線評估技術更改請求，並肯定如何對設計進行調整，以最好地處理此類請求。架構師還要密切瞭解開發人員的進度，特別要跟蹤系統中模塊間的集成點的狀態。尋找常常對討論進行引導來鏈接多個子系統的開發人員。尋找項目經理能夠依賴其快速地進行與更改和出現的問題相關的風險評估的開發人員。

測試：架構師對系統集成和用戶接受度測試進行指導，並負責評估進度的正確溝通的持續測試結果。尋找理解錯誤模式且善於將測試複查結果轉換爲行動計劃的開發人員。

維護：在維護期間，架構師將發起關於系統集成的討論。不管處理 IT 基礎設施問題，仍是確保部門之間的技術合做，架構師都必須徹底理解應用程序，必須快速學習姊妹應用程序的體系結構，並且必須就集成點和風險進行有效溝通。尋找具備系統集成經驗且表現出快速掌握全貌的能力的開發人員。系統集成是一項獨特的任務。

架構師培養建議

有些組織能比其餘組織更有效地進行架構師培養。若是充分考慮到招聘此類新專業人才的困難，努力促成能鼓勵開發人員發展爲架構師的環境是很是明智的策略。但務必避免對不肯意或不適合走這條路的開發人員進行處罰。組織應該爲開發人員制訂多條發展路線，包括那些願意繼續擔任開發人員的人。對架構師而言，資深開發人員不可或缺。他們能夠實現系統中最關鍵的模塊。經過對其餘開發人員進行代碼檢查和測試支持，他們可幫助確保整體軟件質量，而若是質量不能保證，即便最好的體系結構也毫無用處。

組織應制訂我的評估程序，以鼓勵開發人員考慮其職業目標，其中要包含體系結構設計的選項。應該鼓勵經理在其下屬中尋找體系結構設計人才。應該實現指導計劃，讓架構師與但願成爲架構師的開發人員協做工做。應該鼓勵開發人員經過參加各類協會、撰寫文章和參加會議，從而參與到專業領域中來。經過這樣參與進來，可幫助開發人員重新的角度理解系統，並幫助他們更好地就其認識進行溝通。這樣還能培養可提升效率的重要創新想法。

結束語

開發人員一旦邁出了通向體系結構設計專業方向的第一步，就能夠利用不少資源來得到幫助，其中包括不少來自 IBM 的資源。有時候，此過程的最困難的部分就是第一步，而本文提供了一些線索和提示，經理和開發人員能夠利用其來評估應該鼓勵哪些人努力成爲架構師。

更多內容請關注微信公衆號：it_haha

http://www.uml.org.cn/zjjs/200703062.asp