架構師在團隊里面的角色很獨特。他們不是項目經理，卻確定著何時以及如何交付軟件。他們不是產品經理，卻要確保軟件能夠滿足業務目標。他們也編程，但做得更多的是架構設計，而不僅僅是寫算法和代碼。架構師是軟件開發的核心角色，肩負著與眾不同的職責。
大多數架構師都是技術出身，會編程、能設計高效的算法、懂測試和部署軟件，這些都是架構師必備的技能，但要從程序員成長為架構師，還需要承擔一些新的職責。
定義問題
軟件架構設計是一門以人為本的學科。軟件的所有利益相關方都有著自己對項目的預期，因此架構師要與產品經理、項目經理一起協作，共同定義軟件項目的需求與目標。
許多團隊是由產品經理定義功能特性。功能需求當然很重要，但是架構師更關注質量屬性。除了定義系統的質量屬性，架構師還要密切關注那些影響架構設計方向的約束和特性。
在定義問題的同時考慮架構，才能確保開發出大家都滿意的系統。
拆解系統，分配職責
架構師只有把軟件系統進行分解，才能制定出滿足質量屬性和其他系統需求的策略。例如，可以指定一個組件實現用戶注冊功能，指定另一個組件負責識別貓的圖片；這樣可以分配不同的團隊開發不同的模塊；從而將數據讀取部分從數據寫入部分剝離出來，使得軟件系統具備更高的可靠性、可用性、可伸縮性。
分解系統的重要性還不僅僅體現在上述方面。小對象往往更容易推演、測試、設計。當然，將系統打散之后，要確保能把它們組裝回去，協同工作。
縱觀全局
所有軟件系統都存在于客觀世界的大背景下，比如與之交互的用戶、開發團隊，硬件平臺，甚至包括最初的開發目的，理想情況下，軟件架構應該能與外圍環境和諧共生。
從全局角度考慮整體系統意味著架構師需要處理的不僅僅是技術問題。人員、過程、業務需求以及其他技術和非技術因素都將影響最后的軟件系統。即便是一個小小的設計決策也可能產生深遠的影響。架構師必須高瞻遠矚、縱觀全局，而不能只著眼于局部細節的設計。
軟件設計是一個不斷“掙扎”的過程，在想要達成的目標與必須接受的現實之間尋找平衡。這意味著必須深思熟慮并做出取舍。
學會取舍
假設客戶要求軟件具備高可用性，能夠響應99.9%的請求。我們可以引入冗余元素來提高可用性。這樣設計倒是簡單，但有一個問題：必須采購雙倍的硬件，從而成本也翻倍了。這樣做就是用更高的成本換取高可用性。
放棄一些東西換取其他東西，這在軟件開發中很常見。架構師要找出備選方案，再與各方一起協商如何取舍最合理。
軟件系統的分解和切割也不一定那么“干凈利落”。這就需要折中，也可能會犯錯誤。在開發系統的過程中，還會不斷給架構引入技術債務。
管理技術債務
所有的軟件都有技術債務。架構師知道系統是如何分解的，他們關注大局，指導劃分出來的各個模塊協調工作，還要將業務需求與技術決策放在一起考慮。只有這樣，架構師才能游刃有余地管理技術債務。
技術債務如同一條鴻溝，一邊是當前的軟件系統設計，另一邊是你想要的、能持續產生價值的設計。技術債務的多少可以通過填平鴻溝所需的代價衡量。技術債務就像是軟件系統的副產品。出色的軟件開發團隊會有意引入技術債務來實現更快的交付，后續再逐步地進行償還，從而持續地創造價值。
架構師應該指明技術債務，幫助利益相關方決定采取何種措施管理它們。
提升團隊的架構技能
架構師是整個團隊的導師和顧問。設計炫酷卻無人理解的架構毫無意義。作為團隊的架構專家，有責任向團隊分享知識，讓他們成功地開發出軟件。
架構師應該適時地傳授設計技巧和架構理念。為了傳道，可以與組員結對設計，可以寫文檔授業、解惑，還可以提出建設性地批評。把架構設計當做一項社交活動，讓團隊成員都參與到設計過程中來，這是最有效地提升團隊架構技能的方法。技能的提升對于團隊的成敗將起到決定性的作用。
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。
