架構師雜談

架構師，這個title就和總監之類的title同樣，已經完全被用爛了，但在一個軟件產品的生命週期中，架構師是實實在在的一個極度重要的角色，這篇文章就來說講我以爲的架構師的畫像，到底具有什麼素質的同窗是貼合架構師形象的，同時歡迎你們回覆下在你心目中NB的架構師的畫像是怎麼樣的呢。

業務理解和抽象能力 架構師的第一職責是理解業務，並轉換爲可被研發理解的實現方案，所以業務理解能力是架構師的必備技能，一般來講一個資深的業務架構師，對業務會有很是深的認識和積累，一個極好的業務架構師應該能大概預判業務將來的發展趨勢，以便在系統的可擴展性上留好必定的空間，因此也會很天然的出現有些業務架構師作着作着就乾脆轉爲PD類型的角色。 抽象能力是經過對業務的理解轉換爲系統實現的模型，這顯然也是重要的能力，抽象不少時候也承擔了分解清楚多個團隊的職責，分工清晰化。

NB的代碼能力 之因此如今不少的架構師都會被認爲是大忽悠，就是有一堆頂着架構師頭銜，又不幹活的人（甚至會出現對技術幾乎不太懂的人），光說不幹，再加上說的不靠譜的話天然很容易被認爲是大忽悠，就我本身而言，我一直認爲架構師有個很是重要的職責是編寫整個系統中核心部分的代碼，這個部分並必定是技術挑戰最高的，但對整個系統的質量/成敗與否是具有很是關鍵的控制做用的，因此架構師必須是從寫核心代碼的人中誕生出來的。 在一個跨多領域的大型系統中，架構師不太可能什麼都擅長，不可能寫各個部分的核心代碼，這種時候架構師必定要知道怎麼判斷非本身知識領域的部分實現是否OK，以確保各部分組合在一塊兒的時候是符合架構設計預期的，一般這種確保各部分組織在一塊兒work的機制部分的代碼應該由架構師本身操刀。

全面 全面是一個架構師展示出來的最關鍵素質，全面會體如今三點上：

1. 在面對業務問題上，架構師腦海裏是否會浮現出多種技術方案，這點其實挺重要的，不然可能就會出現明明有一個簡單成熟的方案，但因爲不知道而作了其餘複雜不成熟的方案，因此廣闊的技術視野是架構師的必備，另外架構師不可能所有擅長，在本身不擅長的點上，須要知道找哪一個專業的人是靠譜的，這點也很是重要；

2. 在作系統設計時是否考慮到了足夠多的方方面面： 例如不少系統設計容易遺漏上線環節的細節，致使在上線時發現漏掉了什麼考慮，臨時解決或只能重來，記得有一年我作的一個設計沒有考慮到上線階段的一個細節，致使上線的時候發現因爲網段的問題徹底不work，而且沒有臨時解決方案，只好重來，系統設計不只僅指導研發同窗怎麼寫代碼，也包括指導其餘全部相關技術同窗的工做； 又例如我2008年在作服務框架設計的時候，集羣和集羣之間經過硬件負載均衡設備來訪問的，鏈接的方式是單個長鏈接，這個設計致使了運行過程當中若是要發佈被調用的服務方，很容易出現壓力都集中在前面重啓的機器上，這也是典型的整個鏈路沒有考慮清楚形成的設計問題； 再例如2013年我在作一個比較大範圍的系統改造的設計時，因爲對其中一部分的軟件瞭解的不夠，判斷錯誤，致使後來這個改造在進行過程當中才發現有些須要改造的關鍵軟件的設計作的太粗糙，最後上線進度差很少推遲了一個多月，並且那些後來補的設計都是緊急作的，風險很是高； 回顧本身設計過的軟件，發如今這個點上犯的錯能夠講好幾天，看來我應該整理另一篇文檔《我在系統設計上犯過的xxx個錯誤》，裏面有些其實靠一份好的系統設計模板也許就能避免掉，一份好的系統設計模板是能夠幫助架構師思考全面些的。

3. 在作系統設計時是否考慮到了將來的一些發展，儘量不要出現將來的一點變化就致使如今白乾或要花大量力氣來改造的現象，想當年作服務框架的時候，後來就發現因爲當年作設計的時候沒有考慮到未來服務調用trace的問題，致使了後來爲了彌補這點花了巨大的力氣（不是技術上，而是實施上）。

全面須要架構師有足夠廣的技術領域知識和足夠多的經驗積累，從全面這點就能夠看到架構師的工做毫不是畫幾個框，連幾根線那麼簡單。

對架構師全面這點的挑戰，會隨着系統的範圍越大（一個系統的設計，和100個系統組成的大系統的設計挑戰是徹底不一樣的）而變得越難，不管是知識的廣度、考慮的點的覆蓋度、仍是將來趨勢，更復雜的狀況甚至會出現架構的調整對應着組織結構的調整，這種也要考慮到，例如服務化這種大的架構改造，就意味着專職的專業領域服務團隊的成立。

全局 全局觀一般是指在系統設計時是否考慮到了對上下游的系統的影響，畢竟一般所設計的系統不是一個孤立的系統，若是沒有足夠好的全局觀，有可能會致使本身的系統作完上線，其餘上下游系統（尤爲有些連上下游是誰，怎麼用的都不知道的狀況下）出現問題，這種案例一樣很多。

權衡 權衡一樣也是架構師極度重要的能力，或者也能夠認爲是決策能力，技術方案的拍板是一個架構師最重要的職責。 上面說的全面是架構師在思考時開的過程，而權衡就是收的過程，收的過程結束基本就意味着技術方案的肯定，同時也肯定了節奏，權衡在兩點上會體現的特別突出：

1. 技術方案決策原則 一般一個問題都會有多種可解決的技術方案，怎麼來決策就相當重要了，而決策一般又和全面相關，大的來講一般決策的原則就是性價比和可持續發展。 性價比簡單來講是方案的實現成本，這個成本要包括很是多的方面，例若有些場景可能會是用硬件解決看起來是花錢，但最終折算成本是最划算的，不少系統設計在決策性價比時都過於隨意，例如一個另外常見的場景就是建設一套新系統替代舊系統，這個時候可能徹底沒考慮舊系統的遷移代價甚至超過了改造舊系統的代價； 可持續發展簡單來講就是所選擇的技術方案在公司是否可持續，例如簡單的案例是公司主體的研發人員都是php，卻搞一個其餘語言，且只有極少人懂的（固然，這仍是要看性價比，若是搞一個其餘語言帶來的效益超過了語言/人才體系的更換成本），又例如引入一個開源產品，有無專業團隊維護這都是要考慮的關鍵因素。

2. 優先級和節奏控制 常常我會問作系統設計的同窗一個問題：對於這個業務場景而言，在系統設計上最須要把握的一個點是什麼；這是一個關鍵問題，全面意味着考慮到了不少地方的問題，但一般業務需求實現都是有很強的時間要求的，所以在這個時候必須考慮清楚不一樣點的優先級，同時也包括技術方案在決策時也要作出取捨，有可能選了一個不是那麼好的技術方案，但經過留下一些可改造的空間，爲之後的重構作好鋪墊，那就是很不錯的，尤爲技術同窗有些時候比較容易陷入解決技術問題的場景去，但那個問題其實有可能不是現階段最重要的。

其實優先級和節奏控制是我認爲一個最NB的架構師的最佳體現，優先級意味着把握住了重點，能夠確保在所設計的架構指導下業務實現不會出現大問題，節奏控制則意味着全面，爲未來作好了鋪墊