IBM DeveloperWorks 中國: 如何從開發人員走向架構師

抽象思維和分析：架構師必須能夠了解表述模糊的概念并将其變成相關各方能夠了解的項目構件。開發人員經常具有很強的數學能力，而好的架構師則傾向于表現出更強的口頭表達能力。架構師可以偏愛任何經典的、經過時間考驗的軟體系統開發方法。

　　很多架構師都是從好的開發人員逐漸過渡而來的，但并非每個好的開發人員都希望成為架構師，而且他們并不是都适合做架構師。無論您是打算進行職業轉型的開發人員，還是尋找能承擔體系結構設計責任的合适人選的經理，都務必對此轉型過程有個清楚的了解。本文将讨論從實作專家到架構師的過渡過程。

　　在尋找優秀的指揮的時候，您首先要找的是一名優秀的音樂演奏家。但并非每個音樂演奏家都能成為優秀的指揮。架構師的專業發展方面也與此類似。越來越多的 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 的資源。有時候，此過程的最困難的部分就是第一步，而本文提供了一些線索和提示，經理和開發人員可以利用其來評估應該鼓勵哪些人努力成為架構師。