架構(gòu)思維 != 思考架構(gòu)。
架構(gòu)思維是：
- 了解架構(gòu)與設(shè)計之間的差異，并了解如何與開發(fā)團隊合作以使架構(gòu)正常工作。
- 這是指擁有廣泛的技術(shù)知識，同時又保持一定水平的技術(shù)深度，使架構(gòu)師能夠看到其他人看不到的解決方案和可能性。
- 它涉及了解、分析和協(xié)調(diào)各種解決方案和技術(shù)之間的權(quán)衡。
- 它是關(guān)于了解業(yè)務驅(qū)動因素的重要性以及它們?nèi)绾无D(zhuǎn)化為架構(gòu)問題的。
架構(gòu) vs. 設(shè)計
架構(gòu)師負責諸如分析業(yè)務需求以提取和定義架構(gòu)特征（"-ilities"），選擇適合問題領(lǐng)域的架構(gòu)模式和風格以及創(chuàng)建組件（系統(tǒng)的構(gòu)建模塊）之類的事情。 然后將通過這些活動創(chuàng)建的工件移交給開發(fā)團隊，該團隊負責為每個組件創(chuàng)建類圖、創(chuàng)建用戶界面屏幕以及開發(fā)和測試源代碼。
架構(gòu)師和開發(fā)人員必須在同一個虛擬團隊中才能進行這項工作。此模型不僅促進架構(gòu)與開發(fā)之間的強大雙向通信，而且還允許架構(gòu)師為團隊中的開發(fā)人員提供指導。
技術(shù)廣度
與必須具備大量技術(shù)深度才能執(zhí)行其工作的開發(fā)人員不同，軟件架構(gòu)師必須具有相當多的技術(shù)廣度才能像架構(gòu)師一樣思考并以架構(gòu)的觀點看待事物。 知識金字塔說明了這一點。
- 您知道的東西包括技術(shù)人員每天用來執(zhí)行工作的技術(shù)，框架，語言和工具。
- 您不知道的東西包括技術(shù)人員了解或聽說過但很少或沒有專門知識的那些東西。
- 您所不知道的東西是知識三角中最大的部分，包括全部技術(shù)，工具，框架和語言，這將完美解決技術(shù)人員要解決的問題 ，但技術(shù)人員甚至都不知道那些東西存在。
隨著開發(fā)人員過渡到架構(gòu)師角色，知識的性質(zhì)也會發(fā)生變化。 架構(gòu)師價值的很大一部分是對技術(shù)及其如何解決特定問題的廣泛了解。
廣度比深度更重要。 由于架構(gòu)師必須做出使功能與技術(shù)約束相匹配的決策，因此對各種解決方案的廣泛了解非常有價值。
我們的知識金字塔說明了架構(gòu)師與開發(fā)人員相比在根本上有何不同。 開發(fā)人員將整個職業(yè)生涯都花在磨練專業(yè)知識上，而轉(zhuǎn)變?yōu)榧軜?gòu)師的角色意味著這種觀點的轉(zhuǎn)變，這對許多人來說都是困難的。 反過來，這導致了兩個常見的功能失調(diào)：首先，架構(gòu)師試圖在各個領(lǐng)域保持專業(yè)知識，在這些領(lǐng)域都沒有成功，并且在過程中陷入困境。 其次，它表現(xiàn)為過時的專業(yè)知識、錯誤的感覺是您過時的信息仍在前沿。 我們在大型公司中經(jīng)?？吹竭@種情況，在大型公司中，創(chuàng)建公司的開發(fā)人員已經(jīng)擔任領(lǐng)導角色，但仍然使用古老的標準來做出技術(shù)決策。
分析權(quán)衡
像架構(gòu)師一樣思考，就是要在每種解決方案（無論是技術(shù)解決方案還是其他解決方案）中進行權(quán)衡，然后分析這些權(quán)衡以決定最佳解決方案。架構(gòu)是您無法使用的工具。
建筑中的一切都是權(quán)衡的，這就是為什么宇宙中每個架構(gòu)問題的著名答案都是"取決于"。 盡管許多人對此答案感到越來越煩惱，但不幸的是，這是事實。
從架構(gòu)上考慮不僅要考慮給定解決方案的優(yōu)勢，而且還要分析與解決方案相關(guān)的負面因素或權(quán)衡取舍。 軟件架構(gòu)師將分析主題解決方案的負面影響。
軟件架構(gòu)中的一切都有一個權(quán)衡：優(yōu)點和缺點。 像架構(gòu)師一樣思考是在分析這些折衷，然后問“哪個更重要：可擴展性或安全性？” 不同解決方案之間的決定將始終取決于業(yè)務驅(qū)動因素，環(huán)境以及許多其他因素。
了解業(yè)務驅(qū)動因素
像架構(gòu)師一樣思考是在理解系統(tǒng)成功所需的業(yè)務驅(qū)動程序，并將這些需求轉(zhuǎn)換為架構(gòu)特征（例如可伸縮性，性能和可用性）。 這是一項艱巨的任務，需要架構(gòu)師具有一定程度的業(yè)務領(lǐng)域知識，并需要與關(guān)鍵業(yè)務利益相關(guān)者建立健康，協(xié)作的關(guān)系。
平衡架構(gòu)和動手編碼
架構(gòu)師面臨的困難任務之一是如何在動手編碼和軟件體系結(jié)構(gòu)之間取得平衡。 我們堅信，每個架構(gòu)師都應該編寫代碼并能夠保持一定水平的技術(shù)深度。 盡管這看起來很容易，但是有時卻很難完成。
在動手編碼和成為軟件架構(gòu)師之間尋求平衡的第一個技巧是避免瓶頸陷阱。 當架構(gòu)師在項目的關(guān)鍵路徑（通常是基礎(chǔ)框架代碼）中擁有代碼所有權(quán)并成為團隊的瓶頸時，就會發(fā)生瓶頸陷阱。
第一種方法是頻繁進行概念驗證或POC。 這種做法不僅要求架構(gòu)師編寫源代碼，而且還通過考慮實現(xiàn)細節(jié)來幫助驗證架構(gòu)決策。
我們在進行概念驗證工作時的建議是，架構(gòu)師應盡可能編寫最佳的生產(chǎn)質(zhì)量代碼。 我們推薦此做法有兩個原因。 首先，通常，一次性的概念驗證代碼會進入源代碼存儲庫，并成為其他人遵循的參考體系結(jié)構(gòu)或指導示例。 架構(gòu)師想要做的最后一件事就是將他們的一次性代碼松散地表現(xiàn)出來。 第二個原因是，通過編寫生產(chǎn)質(zhì)量的概念證明代碼，架構(gòu)師可以練習編寫高質(zhì)量，結(jié)構(gòu)良好的代碼，而不是不斷開發(fā)不良的編碼實踐。
作為一名架構(gòu)師，動手實踐的最后一種方法是進行頻繁的代碼審查。 雖然架構(gòu)師實際上并未編寫代碼，但至少它們與源代碼有關(guān)。
