架構漫談（七）：不要空設架構師這個職位，給他實權

上篇：架構漫談（六）：軟件架構究竟是要解決什麼問題？

　　什麼是架構師

　　在以前的幾篇文章中，常常會提到架構師這個詞。咱們已經定義了什麼叫架構，那怎麼定義架構師呢，是否是作架構的就叫架構師了？ 沒有這麼簡單，本篇嘗試討論一下這個問題。

　　架構師的前提條件

　　若是一我的在工做中，只是致力於完成本身的工做，以作好本身的工做爲主要目標，那麼最多隻能成爲一個工匠，沒法成爲一個架構師。由於這個過程解決的仍是本身的問題，並無時間的壓力，能夠隨意何時作完均可以。

　　當咱們所作的工做是處於社會的分工的一環，須要幫助別人解決問題，而且按時解決別人的問題成爲咱們本身的問題的時候，咱們就有了時間壓力，潛意識裏會天然而然的有一種對時間的恐懼。這個恐懼在潛意識裏面會千方百計推進咱們採用各類手段，以便及時的完成工做，換取報酬。甚至會加班加點，不擇手段。

　　若是咱們還生活在這個恐懼下面，是不可能成爲架構師的。要成爲架構師，必需要超越這個恐懼纔可以看清楚，咱們要解決的是別人的問題，不是本身完成工做的問題。由於僅僅是完成了本身的工做，也並不必定就解決了別人的問題。若是別人的問題沒有解決——即便咱們認爲本身的工做完成了——咱們的工做實際也沒完成，由於咱們工做是否完成，是別人說了算的，不是咱們本身。

　　爲何會有這個對時間的恐懼和壓力呢？這是由於咱們把完成本身的工做當成了咱們的最大利益。若是別人的問題沒有真正的解決，必然會以爲付出的報酬不值得，咱們的利益其實是受損失了。這和咱們因此爲的偏偏相反，由於咱們所能獲得的工做只會愈來愈少，別人會愈來愈不肯意依賴於咱們。

　　另外一方面也說明，咱們對本身所從事的工做，尚未足夠的自信，咱們解決本身的問題還有困難，纔會這麼在乎，並恐懼。若是咱們把完成別人工做當成本身的最大利益，這個對時間的恐懼天然就會消失，這個時候就天然而然的開竅了，就知道怎麼去發現問題了。只有作到這一點，才能在本身所服務的領域創建起自信，成爲一個合格的架構師。

　　其實剛開始通常是硬着頭皮去克服對時間的恐懼和壓力的，一點自信都沒有。但只要作成功了一次（只要真的捨得這麼去作了，想不成功也很難！），自信就開始慢慢創建起來了，這個時候就是咱們開始慢慢變成架構師的時候。你們就當着上當一回，試試看。

　　如何發現「是誰的問題」

　　當咱們真正專一於別人的問題的時候，咱們本身的理想，抱負，對技術的追求都不算什麼了。這些理想，抱負，對技術的最求，不就是要達到本身的利益嗎？ 只有幫助別人解決了問題，這些理想，抱負，對技術的追求才可能實現，不然這些理想，抱負，對技術的追求有什麼意義，能獲得什麼利益？

　　這個時候就會真正的開始思考，別人究竟有什麼問題。其實也很簡單，和咱們本身面臨的問題同樣，別人的問題也都是如何獲取更好更多的利益。咱們本身想明白了這一點，天然也就能想明白別人的問題。這個時候就可以問出正確的問題：若是問題不解決，究竟誰會有利益的損失？ 若是問題解決了，究竟誰會有收益，誰的收益最大？ 回答了這兩個問題就找到了問題的主體。只回答一個是沒有用的，由於不少時候這個世界的事情，權責是不對等的。明白了這兩個問題，咱們只要讓事情權責對等起來，讓每一個人爲本身的權利產生的結果負有義務，大部分時候咱們本身根本就不須要作什麼，問題就都解決了。這就是最高明的架構師。

　　架構師的權利和義務

　　架構師是要去平衡別人的利益，甚至會調整別人的利益的。一旦架構師是全心全意的爲別人的利益服務，天然而然的架構師就擁有了強有力的影響力，確定會是一個leader。可是隻是民意上的leader是沒有用的，不能徹底發揮架構師的能量。

　　架構師必須是一個組織的領導人，有權利調動這個組織的架構，纔可以更好的發揮架構師的做用，更好的把利益的調整落到實處。因此不少公司設了不少架構師的職位，可是並不具有調動組織架構的權利，那麼這個架構師的職位必定是形同虛設。架構師只可以經過創建某些流程來行使架構師的權利，好比強制架構review，反而會形成不少內部沒必要要的衝突，最終都會致使這些流程流於形式，得不償失。相信不少人都已經經歷過這些，但彷佛不多有人回去探討這是爲何。

　　反過來，具有架構師能力的組織領導人，必定是一個很好的領導，這個組織必定是很健康向上的，由於每一個人的權利和義務就是比較均等的。而且這類領導對於組織成員權利和義務的對等情況會很是的敏感，會及時的調整組織架構，在問題發生以前就解決了。這樣這個組織就會具有更好的抗壓能力，可以更好的爲這個組織的客戶服務，這個組織的成員心裏必定都是比較平衡的，每一個人的能力都可以獲得比較好的發展。固然讀者可能又會說，這不是管理學的東西嗎？ 是的，但也是架構的問題。全部架構的核心就是組織架構。或者也能夠這樣說，一個合格的組織領導人，必定必須是一個合格的架構師。

　　架構師的義務彷佛不用說了，你們提的要求可能比我提的都高 —— 固然是發現問題而且解決問題。架構師必須可以超越對時間的恐懼 —— 也就是說必須具有了必定程度的自信，哪怕是裝的，去真正的發現問題的主體，識別真正的問題，並把這個行爲變成爲本身面對問題的第一反應。架構師還必需要明白，所給出的解決方案 —— 架構的分拆、合併方案，只有讓問題的主體的權責對等，纔可以真正的解決別人的問題。通常明白了問題的主體，以及主體的利益所在，作到這一點也沒有問題。

　　架構師和技術

　　不少人會問，特別是作軟件行業的，架構師是否是須要學習技術，甚至是學習語言？ 若是一個架構師還有這個困擾——就如問這個問題的人，說明目前還不具有作架構師的能力，或者說還不具有對本身領域——哪怕是技術領域——的自信，更別談業務領域了。

　　由於技術和語言，都是用來識別和解決所服務的主體的權責，保護並提高所服務的主體的權利的。特別對於軟件領域來講，必須明白軟件自己是怎麼回事，解決什麼問題，還要解決軟件所服務的對象的領域自己是怎麼回事，解決什麼問題，這就要求更高了。語言和技術應該是隨手拈來纔對，對於架構師這些都是工具。學習技術和語言，若是明白了這些技術和語言要解決的是誰的問題，什麼問題，學起來是很是快，很是容易的。

　　一樣，採用哪一個技術或者語言，只要某個技術或語言所解決的問題的主體，以及所解決的問題，和本身所面對的問題的主體和這個主體要解決的問題，這二者是匹配的，那麼這個方案的成本是最低的，所採用的技術或者語言就是靠譜的。沒有趁手的工具或語言的狀況下，本身設計一個也不難，由於很清楚本身要什麼。要不要本身作，無非是一個成本問題，也就是利益問題。而且從這個思路下去，選擇的工具和語言確定都是最簡單的，成本是最低的。由於架構畢竟解決的仍是人的利益問題，成本越低越好，這個成本固然是長期整體成本，不是眼前的短時間成本。

　　下篇：架構漫談（八）：從架構的角度看如何寫好代碼