軟件架構師角色分析

近年來移動應用開發正在迅速增長。有無數的移動Web應用程序在互聯網上公布，所以了解關於移動開發框架的信息變得尤為重要。下面就讓我們來了解一下軟件架構師。

架構與實現的分離

在公司晉升體系中，軟件開發者可以成長為軟件架構師。架構師通常位於一個架構團隊，這個團隊負責早期應用架構設計，開發節點的驗收，產品發布前的批准。

開發團隊接收架構師的要求。在開發中，開發團隊在某些檢查點或者當架構師定義的要求無法完成時與架構師進行溝通。

產生鴻溝

Doug Sundheim的文章消除戰略和執行之間的鴻溝見解獨到地描述了當架構師與開發團隊分離工作所產生的風險和失衡。

我同意Doug—尤其是與軟件項目相關的內容：

“過程總是有點不愉快。執行者粗淺的視角與戰略家高遠的視角總是區別很大。”

架構師呆在與實現獨立的角色中時間越長，他們對新工具、流程、范型的成熟度和風險的評判越不合格。架構師預先進行的決策變成了開發團隊的痛苦。開發者對看不見摸不著的架構師很失望。架構師對“敵對的”開發團隊也很失望。

我懷疑，建立或維護一個將戰略和執行分離的組織結構的管理者認為，雙方的人員能夠合理地行動，建立聯系，有效地溝通來完成工作。但是就像Doug闡述的一樣：

“不幸的是，完全不是那回事。實際上經常發生的是雙方都在踢皮球。最壞的情況，戰略者懷有優越的、分離的觀念：我們是思考者，其他人會付諸實施。他們不花點心思來搞明白實現這個想法需要什麼。他們不提前與執行者溝通詢問，“這實際上怎麼實現呢?”執行者也有責任。通常，他們並不完全理解這個戰略之下的想法。他們只取表面含義，並且不詳細詢問...

“問題是雙方都不認為自己有責任理智地將雙方拉回來。他們之間產生了鴻溝，並希望這個鴻溝能夠奇跡地自我愈合。但它不會。事情就因此而失敗。”

Doug總結出，戰略者和執行者消除鴻溝用的是信念(beliefs)而不是過程(process)。你應該讀讀Doug文章中總結的信念。他們總結了在一個等級組織結構下團隊或個人共同工作的觀念模式(mindset)。

更好的、一體的結構

我懷疑分離的架構工作和團隊的出現包括以下原因：

雇傭效率(工作描述和經驗要求)

運營效率(分配架構師到各個團隊)

晉升和職業成長激勵

但是我認為，一個更好的能將架構和實現團隊組成一體的組織結構，也能滿足上面觀點所代表的邏輯。架構和實現不應該是分離的工作。

一個組織應該雇傭高級開發者來負責架構，而不是雇傭架構師。每個開發團隊都應該有一個人來負責架構工作。這個負責架構的人應該對團隊效益負責，而不是命令。

詳細地說，將架構師安排到實現團隊有如下好處：

消除戰略和執行的分離，以及與此組織結構相關的功能失調風險。

架構師可以在實現的整個過程作出決策並收到反饋。反饋循環可以提升學習和未來更好的決策。

架構師可以對開發過有所貢獻。

架構師可以了解在實現過程中有很大幫助的新工具、過程和范型。

架構師可以教授初級開發者架構和開發實踐。架構師身處早期架構決策，期間不斷編碼，能偶與團隊成員建立和維持互信和尊重。互信和尊重能夠促進教學相長。

總結來說，一體架構方法能夠形成：

提升的士氣

提升的質量

提升的執行速度

產品開發過程中的員工自由發展

使用一體架構模型的雇傭效率不會比傳統上雇傭架構師的方式更有挑戰性。雇傭有架構經驗並且不願意放棄寫代碼的高級開發者。

運營效率可以使用Spotify組織模型中的幾個觀點來保留。架構師可以通過參加Chapters和Guilds(Spotify組織模型的術語，意思是各種協會)互相支持、互相學習。Chaperts和Guilds使不同團隊的架構師可以分享知識和工具，所有團隊都能從中受益。個人、團隊、公司的成長會更快。單個團隊的獨特見解可以帶來放大的規模效益。

晉升和職業成長激勵也簡單。當有人勝任架構師角色時，獎勵他們獲得了一項能力，而不是晉升他們到一個新的工作。給予認同，並相應地調整薪酬。

一體結構的風險

一體架構模型的一個風險是架構師可能聚焦在實現上。在架構和實現職能間的切換可能導致結構和紀律變得松散。

如果Chapter和Guild的溝通不能提供足夠的檢查和平衡，團隊應該經常使用暫時休息並把握整體規則。讓團隊在一個總體高度來審視自身工作有沒有滿足整體的架構方案。

以上就是精品為您准備的關於軟件架構師的信息，希望對您的生活工作有幫助，祝您生活愉快。