第12章 拓展T

不管別人怎么說，軟件架構都不是一個“后技術”或者“非技術”的工種。在白板上畫一堆框、線和云，交出這種“軟件設計”，可不是軟件構架師所為。

進一步的技術能力

“T”指的是技術，這也正是優秀的軟件構架師應該懂得的。作為軟件開發者，我們傾向于去搞懂編程語言語法、API、框架、設計模式、自動化單元測試和其他所有日常使用的底層技術。對一個軟件構架師來說，這些也是基礎知識。為什么？因為扮演軟件構架角色的人要懂技術，這樣他們至少能如實回答以下類型的問題。

? 該方案是否有效？

? 我們要這樣去構建嗎？

然而，從熟練掌握不同編程語言的學習曲線來看，軟件專業人員常常只精通一到兩項技術。最后，這些人都會被叫作“Java開發者”、“Oracle開發者”什么的。我本人曾是如此，也在很多組織中目睹這種情況。如果你還對編程語言的宗教戰爭感到困惑，看看有多少這樣的前綴吧。

盡管我們努力保持開放的思維，但還是受困于單一的技術棧。其實這也沒什么錯，但你不得不小心地保持開放思維。俗話說，“如果你只有一把錘子，一切看起來都像釘子”。獲得經驗是學習之旅的重要組成部分，但不要被經驗束縛。比如說，并不是每個軟件都需要一個關系型數據庫，但在團隊勾畫候選的軟件架構時，往往第一個就會畫它。

知識面寬

這讓我想談談為什么技術知識面寬對軟件構架師來說也很重要。當然，他們可能是Java或者Oracle專家，但軟件構架角色的要求更高。例如，他們要能夠回答以下類型的問題。

? 和其他可選技術相比，我們所選的是否最合適？

? 對該系統的設計和構建，還有哪些選擇？

? 是否應該采用一種通用的架構模式？

? 我們是否明白所做決策的利弊？

? 我們照顧到了品質屬性的需求嗎？

? 如何證明這種架構行之有效？

軟件架構師是通才型專家

我所知大部分最優秀的軟件設計師都有軟件開發背景。這并不意味著他們是團隊中最好的程序員，但他們能夠在底層細節和大局之間切換。他們還有著深厚的技術積累，以及從多年軟件構建的經驗中獲得的廣闊的知識面。但他們不能（也不會）總是知道一切。再加上也很難找到一個只使用單一技術棧的軟件系統。我在職業生涯中，見過一些采用混雜技術棧的系統，包括：

? 針對多個Oracle數據庫的微軟.NET桌面客戶端；

? 通過一組Java EE網絡服務從Oracle數據庫拉取數據的微軟ASP.NET網站；

? 從Java編寫的REST服務拉取數據的iOS和Android移動應用；

? 用微軟.NET或Ruby編寫的多個服務構成的微服務架構；

? 從微軟Dynamics CRM系統拉取數據的微軟ASP.NET網站；

? 通過微軟.NET/Windows通信基礎服務拉取數據的微軟SharePoint網站；

? 與SAP集成的Java EE網絡應用程序；

? ……

雖然一般性的設計知識、技巧、模式和方法通常適用于許多不同的技術，但不明白如何將其成功應用在底層細節上可能會導致問題。這是否意味著對任何特定軟件系統中使用的所有技術，軟件架構師都應該是專家？不，合作才是關鍵。找到那些知你所不知的人，與他們緊密合作。沒有誰說軟件構架的角色不能分享，而且欣然認識到你的知識差距往往是創造更和諧的工作環境的第一步。結對編程有好處，那么為什么不能結對架構？

軟件架構是技術活

支撐軟件架構角色的技術知識需要深度與廣度并存的知識組合。如果設計軟件、畫架構圖的人回答不了該架構是否行之有效，那他們可能不是這項工作的正確人選。軟件架構絕對是一個技術工種，但光有技術還不夠，良好的軟技能也至關重要。