背景
周末參加topgeek組織的2016年度中國架構(gòu)師大會，日程之一是圓桌會議：“如何成為頂級架構(gòu)師”。有意思的是，四位嘉賓一致和不寫代碼的“PPT架構(gòu)師”撇清了關(guān)系，均表示至今還在擼代碼。不出意外，臺下的架構(gòu)師們報以經(jīng)久不息的掌聲。
怎么定位軟件架構(gòu)師？
角色是無法自賦其意義的，就好比我偶爾喝高了，斗膽號稱一家之主，老婆大人一定會招呼我一個巴掌:-)。角色存在的價值必須從他和環(huán)境的相互關(guān)系中去尋找。我們試著看看一個典型的軟件開發(fā)組織中不同干系人對架構(gòu)師的期望。
客戶
不要奇怪，客戶也會關(guān)心架構(gòu)，比如兄弟所在的行業(yè)，你不把自己的技術(shù)方案和演進(jìn)路線說清楚，客戶是不敢把他上億的資金還有他未來10數(shù)年的基礎(chǔ)設(shè)施演進(jìn)押在你身上的。
產(chǎn)品經(jīng)理
期望方案方案價廉物美，關(guān)鍵還要能頻繁修改，能迅速上線。
CTO
CTO是老板在技術(shù)方面的代理人，他既關(guān)心公司的當(dāng)前利益也關(guān)心長期利益。他的期望是架構(gòu)師的方案既能滿足當(dāng)前需求，也匹配公司的長期技術(shù)演進(jìn)路線。傳說CTO還有一個變態(tài)的需求--你得在電梯開門之前把你的思路講清楚。
其他架構(gòu)師
你的架構(gòu)至少得通過其他架構(gòu)師的評審。你得證明你的架構(gòu)是“好”的。
項目經(jīng)理
技術(shù)風(fēng)險是否可控，架構(gòu)是否能在期望的時間內(nèi)被團隊落實，系統(tǒng)是否被有效分解為子系統(tǒng)以便安排團隊齊頭并進(jìn)。
開發(fā)團隊
開發(fā)團隊最關(guān)心的是自己負(fù)責(zé)的子系統(tǒng)的職責(zé)是否被清晰定義。這樣他們可以安排資源，估算進(jìn)度，安心擼代碼。此外，不同的團隊領(lǐng)導(dǎo)可能會對開發(fā)任務(wù)在不同領(lǐng)域（團隊）的映射有不同想法，這個模塊應(yīng)該是隔壁領(lǐng)域的自留地？開發(fā)團隊中有一些能人，他們可能會對你的架構(gòu)評頭論足；開發(fā)團隊中還有一些初級員工，無論你覺得你的架構(gòu)闡述得多么清晰，他們總是一臉茫然。
以上這些職責(zé)都假設(shè)架構(gòu)師技術(shù)功底扎實，但真正的挑戰(zhàn)其實在于溝通技能。顯然，不要說擼代碼，就算能整出一套漂亮的PPT也未必搞得定樓上各路諸侯：
架構(gòu)是份新工作
從局部到全局
既然貴公司設(shè)定了架構(gòu)師這個職位，說明貴老板已經(jīng)意識到系統(tǒng)的規(guī)模已經(jīng)超過了單個能人能搞定的程度了。你現(xiàn)在的工作內(nèi)容絕不會是以前的工作減去編碼。橫向看，你要搞清楚系統(tǒng)所涉及的不同方面，你以前可能是后臺的高手，現(xiàn)在可能要涉及到前端，以前可能是支付領(lǐng)域的高手，現(xiàn)在可能還要看看物流；縱向看，你得對這個系統(tǒng)接下來的發(fā)展有點想法，你的架構(gòu)制品首先要滿足當(dāng)前需求，這是沒錯的，但是人們期望它不要和可以看見的未來沖突......
你之前是個C#高手，或許你意識到用這個技術(shù)的兄弟公司越來越少了，少到HR都不好找人了，而且你聽說有個叫阿里的公司開放了很多用Java寫的中間件，似乎你們恰好也用得上，那下一步是不是要把平臺切換到j(luò)ava呢？對了，老大昨天很開心的告訴你，用java的競爭對手最近正在為核心員工被淘寶挖走發(fā)愁哪！看來這個決定似乎不是那么好做了。
從代碼到PPT
是的，我猜中了，你痛恨寫文檔，而且你還知道有個什么宣言支持你說凡是不是代碼的東西都是浪費。如果我又沒猜錯的話，你在這家公司的成長路線是這樣的：
成長的煩惱
小兵變牛人
一開始，你默默無聞，埋頭coding，首先是公正的電腦上帝發(fā)現(xiàn)，你的程序從來不出錯，后來測試組妹妹也發(fā)現(xiàn)，bug都是其他人的（再后來，即便是你的bug她也不敢相信是你了），一直到這個時候，你的代碼主要是被機器閱讀的，機器好啊，它老人家只管對錯不挑美丑，回車鍵一敲，編譯，單元測試，部署，自動測試，OK，一把全過，多爽啊！你一定很回味這個感覺對不對？接下來，組長大哥也發(fā)現(xiàn)你是一個人才，開始分配一些體量大一點的工作給你了。
秀才遇到兵
為了控制代碼質(zhì)量，你們開始做代碼評審了，有些同事（或許就是你）覺得代碼能工作，跑得快還不夠，還要寫的好，媽蛋！什么叫寫的好寫的壞啊，總之評審會是亂成一鍋粥，每個人都振振有詞，每個人都說服不了別人！是的，現(xiàn)在沒有電腦這個說一不二的裁判了，上帝已死！
你不得不思考代碼好壞的客觀標(biāo)準(zhǔn)了，你腦補了一堆實現(xiàn)模式，設(shè)計模式，架構(gòu)模式，還有什么壞味道之類的，停一停，憑什么這些家伙講的就是對的？于是你進(jìn)一步鉆到故紙堆里，發(fā)現(xiàn)這些真理后面的真理在上個世紀(jì)70年代就整理好了，而且還要言不煩。于是你信心滿滿，下次代碼評審會侃侃而談，不對！那些在你看來就像“兩點之間直線最短”這么鐵的設(shè)計準(zhǔn)則，為什么寫漿糊代碼的兄弟就是死活聽不進(jìn)去！作者自己，一路刨根究底，最后一頭扎進(jìn)認(rèn)知心理學(xué)
這下你知道生活不容易了吧，自己搞懂是一回事，把真理傳播給別人是另一回事，否則的話，小學(xué)班上的王二小也不會老是數(shù)學(xué)考不及格了。沒錯，我相信你從此以后真的是把代碼寫好了，但是你并沒有說服其他人。
架構(gòu)編檔
現(xiàn)在你是架構(gòu)師了，什么，拿代碼說話？把開發(fā)團隊撤了，就保留你一個人行嗎？一開始，你的文檔整得太細(xì)了，首先你自己覺得這樣寫下去還不如直接上代碼來得爽快，其次軟件團隊覺得你規(guī)定得太細(xì)了，有些地方和實際有出入，沒法照著你寫的做，再次，項目經(jīng)理在催你了，因為還有其他幾個團隊的兄弟等著你的輸入好開張。慢慢的，項目進(jìn)展到集成階段了，你發(fā)現(xiàn)模塊之間的配合才是真正的問題，于是你漸漸不操心局部模塊的問題了。
工作中總是有一些讓人煩心的事，有時候，你躊躇于究竟該用圓角矩形還是直角矩形來表示一個模塊；有時候，你把各種箭頭的形狀都嘗試完了，還是沒法把心中的那個關(guān)系痛快的表達(dá)出來；更要命的是，你絞盡腦汁做出來的PPT,有人覺得他就是看不懂，或者有個點子你明明畫在圖上了，可軟件團隊的兄弟跟你說他壓根就不知道你是這個意思，有時候你明明是這個意思，人家讀者非要感覺是那個意思。
是的，我沒猜錯，UML, 你又找到法寶了?？墒菃栴}還是不斷出現(xiàn)，首先是你自己也總是覺得這東西的表達(dá)能力好像也有那么一點局限，雖然不再為圓角矩形還是直角矩形糾結(jié)了，可是什么關(guān)系都用一條線來表示是不是也太簡陋了，要知道之前你可以直接用大框套小框來表達(dá)包含、用上下關(guān)系來表達(dá)堆疊，多么形象啊，現(xiàn)在都沒啦。
溝通為王
我知道聰明的你最終搞定了架構(gòu)編檔，你能夠得心應(yīng)手的表達(dá)自己的想法了，更加重要的是，別人也能透過文檔看懂你的想法了。而且你還是個技術(shù)牛人，你的架構(gòu)很美！
但是問題來了，你也知道，軟件的質(zhì)量屬性有時候是互相沖突的，有時候為了效率你不得不破壞封裝，有時候為了可靠，你不得不引入冗余，犧牲簡單性....., 問題來了，你覺得簡單性重要，他偏偏覺得效率更加重要，你覺得讓當(dāng)前特性盡快上線迫在眉睫，他覺得把結(jié)構(gòu)整理清楚刻不容緩。
架構(gòu)組中有個把老頑固，他們死活就覺得你的設(shè)計不那么美，雖然私下里你覺得是他們知識結(jié)構(gòu)老化導(dǎo)致的，可是領(lǐng)導(dǎo)說，沒獲得大家的一致同意，你的架構(gòu)就是不能通過，領(lǐng)導(dǎo)還偷偷的告訴你，其實他也同意你的設(shè)計；還有，有時你覺得某個現(xiàn)成的中間件完全能滿足項目的需求，但是會導(dǎo)致某個正在造輪子的團隊關(guān)門......
好悲摧！好不容易把PPT擼順了，到頭來發(fā)現(xiàn)還要去擼心......
臺上的嘉賓，很可能是代碼、PPT、別人的人心、自己的心都擼過一遍了，所以他們有閑暇去擼擼代碼，臺下的你，極有可能剛剛把代碼擼順，你應(yīng)該知道有沒有功夫去享受這份奢侈。
