如何避免自己成為PPT架構師？

01-04

我所理解的PPT架構師的定義：
1、喜歡忽悠概念，擅長寫PPT，畫架構圖。
2、脫離一線開發，對底層基礎知識知之甚少。
3、技術跟風，盲目崇拜所謂熱門的新瓶裝老酒的概念，譬如從前幾年的SOA到這幾年的微服務。

我把問題擴充一下，「如何避免」：

如果你是決定誰做架構師的人，一定把技術資質作為提拔考核之一，實際能力一定要夠，要有成功案例，一定要有名有實，而不是給個虛無的頭銜，安在一個空空的腦袋上，不要以政治和人事的理由提拔任命關鍵技術職位人選。
如果你是不得不管理這類人的人，發現他的缺陷，一定要有組織機制來避免他犯嚴重架構錯誤，一定要避免他一個人獨斷專行，可以考慮建立architectural review board讓技術骨幹來制約他，你也可以指定專門的會議，讓他demo給團隊選型架構的思路，SWOT分析等等。
如果你是這類人的下屬，一定要強化自己技術溝通的能力，碰到這種架構師是對你技術能力和溝通能力的雙重挑戰。技術問題上，發現漏洞，一定不要back down。因為如果你退一步，最後事實的負擔和工作量是你作為實施著來承擔的。他畫好圖講好話工作就完成了，而你的工作才剛剛開始。
如果你就是這個人，我不知道怎麼幫你，你可能就是「彼得原理」說的那個現象，你已經被提拔到了你無法勝任的位置，阿彌陀佛。如果你有自知之明，應該可以意識到自己的技術品位還有待修養，請你保持謙遜，做服務者合作者而不是「管理」者。你要多充電，提升品位修養。
如果你還沒有成為這個人，想規避，那麼八年以下經驗的時候，即使公司給了你頭銜，也不要太把自己當回事，一定要和同事群策群力，集體技術領導，尤其是和技術骨幹。你做demo的時候一定不能只有ppt，一定要有利弊分析，多套方案多個方向的比較，說清楚技術和商業的取捨在哪裡？為什麼做這樣的取捨對公司和大家更有利。你要考慮人的成本，風險，技術大環境，商業的大環境，把這些問題都說清楚，而不只是幾個slide說這裡好，那裡也好，都好所以我們應該用這個。你要明白NO SILVER BULLET不是一句空話。
如果你正做著這樣的事，那麼方案敲定一定要給自己實際coding的角色，哪怕是部分角色，否則這就是一個moral hazzard，做決定的人不必承擔過程與結果的後果，這是很糟糕的情況。所以你要讓自己參與到一線，只有這樣你才能體認架構的好處和壞處，才發自內心知道如何去改進。
如果你是局外人，但可以影響團隊文化，就總是輸出好點的價值觀。如果有人要把架構理解為畫畫圖，然後對碼農指手畫腳的那個人，你就想辦法敲打他一下。他在乎的不是技術，而是一種隱秘的「官本位」妖孽。
如果你怎麼都改變不了這樣的既定事實，哥勸你不要被這樣的人領導，換地兒。

1，做人實在，不忽悠。

2，偶爾參與一線業務開發，經常參與核心功能開發，組織代碼評審，作為講師給他人做培訓

3，秉持一個原則：「適合的才是最好的」。適合包括業務、技術、資源、維護等方面。

擅長寫文檔畫圖是個挺好的技能。

無論做何項目，我都不希望那個主持大局的人只是指手畫腳。如果是程序員，那麼就應該保持貢獻代碼，而且是超出整體質量的代碼。這麼要求，或許有些固執。但我偏執于堅持對那些付出努力堅辛只為了有朝一日擺脫當下狀態的人保留一絲輕蔑的態度。所以，當有不熟悉的同學問起，「你現在還寫代碼啊？」，我只是一笑，「當然寫，三天不寫就手癢了」。如果有更多任務要完成，我會分出工作以外的時間去做。而不壓減編碼第一線的時間。

引自雲風的blog

我在菊花廠參與架構設計小組，在松鼠廠先是負責方案設計，後來逐步負責架構設計，說起PPT架構師以及如何不變為PPT架構師，還是可以談談很多有趣的事情。

【菊花廠】（以下只描述我當時的遇到的情況，不明確是否是普遍現象）

在菊花廠當時是做核心網的，看到的架構師就是題主所謂的典型的「PPT架構師」，也就是說架構師主要是負責進行業務設計和分解，舉例：為了完成某個業務（例如呼叫轉移），核心網要做什麼，HLR要做什麼，核心網要傳什麼信令給HLR，雙方要遵循什麼標準（例如3GPP）。

和通常互聯網行業的技術棧是不一樣的，這個架構中其實不涉及技術細節的，一般不會看到什麼高可用、高性能、可擴展、集群選舉、緩存這些技術的。哪這些實現細節什麼時候體現呢？實際上是後續實施的團隊設計的，但一般不叫架構設計，叫方案設計，且大部分所謂的高可用、高性能都是靠Oracle和IBM來搞定的（一台小型機50萬，一台Oracle 100萬），不需要自己去設計，出了問題也是找Oracle和IBM官方售後。

所以當時我印象最深刻的一件事就是：每當開發團隊問架構師「這個地方怎麼實現」，架構師一般都是「細節我們不討論」 ！！！

當然，每個開發團隊自己負責的系統還是有架構設計的，但這部分的架構一般幾年都難得一變，大部分人一般不會做架構設計，只是做業務設計和開發，因為電信行業對穩定和可靠是第一要考慮的。一旦真正要重新設計架構，就會成立一個架構設計團隊，這時就很有趣了，一部分是做業務架構的（一般都是資歷老的），一部分是做業務開發的（大部分對底層和架構經驗一般，但會有幾個技術高手），所以做架構的過程簡直就是吵翻天了：

業務架構師：「細節我們不討論」

開發人員：「細節不討論我怎麼達到你的目標」

業務架構師：「那是你們考慮的事情」

開發人員：。。。。。（內心千萬隻草泥馬奔騰，什麼鳥架構師）

這種情況下即使有技術高手，也可能會陷入爭論，因為菊花廠這種環境，技術高手都是某個領域深度很深的，但架構設計要求深度和廣度並重，而且以前的經驗都是基於老架構的，在新架構裡面也不一定適應。我記得當時我參與的一個架構設計團隊，幾十號人每天開會開10幾個小時，開了幾個月架構都沒確定。

看到這裡，可能很多人就理解我在嘲諷菊花廠架構師了，其實我不是這個意思，還是行業決定的，電信行業首要考慮的是快速實現業務（這樣就能按照合同提供產品了），系統穩定和可靠（一個月宕機一次的系統沒人敢買），而不是技術有多牛逼！把已有的架構做穩定，細節做精，能用10年絕不會只用3年！所以如果你現在去移動聯通電信看看，可能還能看到2000年開發的系統，只是後來升了幾次級而已，架構是沒變的：）

對於個人來說，能成為PPT架構師那也都是很牛逼的，對業務要非常精通，至於技術么，嗯，那是開發團隊考慮的。

（補充：有網友說這類人員也叫「系統分析師」，比較貼切）

【松鼠廠】

松鼠廠是典型的互聯網行業，業務快速發展，經常變化，而且高性能、高可靠都要自己去設計和實現，用的都是RHEL和MySQL這種開源的便宜貨，所以架構師的要求就高了。

當然，也還是有較多PPT架構師，例如：

1）高性能篇

架構師：我們要實現高性能，每秒TPS達到3萬。

程序員：怎麼實現？

架構師：用netty啊，netty是NIO的，你看業界的好多系統都是基於netty做的

程序員：用netty具體怎麼做呢？

架構師：這個很簡單吧，你去查一下就知道了。

程序員：。。。。。。

註：用netty是實現高性能的可選方案，但關鍵是如何使用netty，例如：IO線程負責編解碼，業務線程如何設計？是設計一個通用的業務線程池，還是根據業務設計多個業務線程池，然後由IO線程進行分發？PING命令是直接在IO線程裡面處理完畢，還是也分發給業務線程池？如何設計客戶端和服務端交互的協議？。。。。。。等等

這些設計點如果不結合業務考慮的話，用netty也可能開發出性能很差的系統。

2）高可用篇

架構師：我們要實現集群功能，達到宕機一台對系統也沒有影響

程序員：如何實現？

架構師：用ZooKeeper呀，Hadoop都用它做選舉呢，我們用肯定夠用了

程序員：用ZooKeeper怎麼做呢？

架構師：你們去看一下Hadoop的就可以了。

程序員：。。。。。。

註：用ZooKeeper來實現業務自己的集群選舉，需要考慮什麼樣的節點才能被選為主機，選為主機後其它節點如何處理，使用ZooKeeper的時候，目錄和節點如何創建如何監聽等。

3）解耦篇

架構師：我們要將系統拆分為更多的子系統

程序員：為啥呢？現在沒什麼問題啊

架構師：你看淘寶都是這樣拆的，我們業務和他們類似，都是交易網站，所以我們也應該這樣拆

程序員：怎麼拆？

架構師：我參考一下淘寶，覺得要拆分為商品、訂單、搜索、後台等子系統。

程序員：。。。。。。

註：方案關鍵是滿足業務發展的需要，而不是盲目照搬業界標杆。

所以在互聯網行業，「PPT架構師」表現不是很明顯，至少在方案裡面能看到Redis、Nginx、ZooKeeper、Docker、Netty等等很多流行的技術術語，看起來就讓人覺得高大上，但本質上其實還是PPT架構師，因為不是用了這些方案就一定能實現目標，關鍵是怎麼用，細節決定成敗。

總結我從不同行業不同經歷來看，「PPT架構師」具有典型的幾個特徵：

1）細節我們不討論

2）用了XX就可以了

3）別人都這麼用

4）我覺得。。。。。。

但並不意味著PPT架構師就一定不好，我覺得要是你能在電信行業成為一個PPT架構師，那也是很厲害的，需要對業務和行業非常精通。但在互聯網行業，還是不要成為PPT架構師了。

現在來談談如何避免成為PPT架構師，我覺得沒有捷徑，就是要有積累，那些號稱3年成為架構師、5年成為CTO，要麼是天才，要麼是騙子，要麼是公司太小：）

積累的方式也和不同階段有關：

1）如果現在還在承擔業務開發和方案設計工作，採用「鏈式學習」和「環式學習」，具體請參考：專訪李運華：程序員如何在技術上提升自己 - 華仔-技術博客 - 博客頻道 - CSDN.NET

2）如果已經承擔架構設計工作了，就需要換一種方式，因為這個時候沒有太多時間參與實際項目開發和編碼了，我的方式就是不要光說不練，一定要自己寫Demo，自己寫個Reactor模式的網路伺服器、自己用ZooKeeper實現一個簡單的集群選舉，都不是很難的事情，具體請參考：

大牛養成指南（3）- 天天寫業務代碼，如何成為技術大牛？https://zhuanlan.zhihu.com/p/22708863

3）多看業界開源方案的實現細節和關鍵點：例如Netty的pipeline和零拷貝，Redis的網路模型和事件設計，雖然有的細節看過不用慢慢就忘記了，但看得多了，能融匯貫通，而且真正要用的時候再看一下很快就能記起來

寫程序的人，尤其是新人容易走入一個誤區。

自己要解決的問題是從來沒有人碰到過的，自己想用的技術必須是最新最時髦的，自己掌握的知識是最前沿最頂端的，自己看待問題是最全面的。

其實呢？大部分人用得都是別人寫過的代碼，碰到的問題網上一搜都有很多最優的解決方案，最新的技術往往只是一個溫室花朵。

你覺得這個寫ppt的人不懂嗎？也許他寫代碼沒有你快，也許他不知道底層架構，但是他其實不需要掌握這麼多。

他需要的是了解和分析客戶需求。

他需要知道如何從全局設計系統專有框架。

他只需要知道開發用到的技術能解決問題就可以了。

如果這些都不知道，我很好奇他怎麼爬到寫ppt的位置的。

其實等你真正成為了架構師就知道，你根本沒時間做別的……還研究代碼？屁股後面十個ppt等著呢，我都是叫個designer 給我做原型驗證的

會畫架構圖很好啊，我見過的PPT架構師只會抄別人的架構圖，而且不知道意思，有的時候還抄錯了，你說這設計怎麼可能做得出來。

一個合格的架構師，對著架構圖，應該可以詳細解釋每一部分的設計，為什麼這麼設計，還有其他哪些替代方案，那些替代方案為什麼不如現在這個方案，這個方案實施的時候可能會遇到哪些困難，大致需要的實施時間是多久，以至於具體實現細節上哪些第三方庫可以用，哪些可以參考，哪些需要重新開發，重新開發的要求以及技術指標是怎樣的等等。

多幹活少廢話

ppt架構師會遭手底下幹活的人恨的。委派任務，不幹活，最後功勞都是自己的。這種人真心不靠譜。

如果做好了，說的清楚。老闆高興，手下人聽的明白，也是好事。程序猿很多都不說人話。說的是猿話，用猿邏輯。說人話的老闆一般都會和程序猿溝通困難。做一個翻譯(產品經理)其實是極好的。

但是本身作為一名架構師，程序猿的領頭猿，自己不搞代碼只搞ppt，遲早藥丸。

因為他們寫不了代碼，才去寫ppt，反正ppt又不能上線跑。

我一般就聽聽，拍兩句，回去該怎麼寫怎麼寫。

一勞永逸的方案：換Keynote

多寫代碼

作為一個挖礦屌絲，我的志向是多挖煤，避免成為監工和煤老闆。

話說煤老闆真垃圾，煤都不會挖，脫離一線生產，對怎麼樣挖煤最省力，怎樣挖煤速度最快，這樣高深的技術，一無所知。整體只會跟人吃吃喝喝，跟地方領導吹牛。

最近老闆要讓我當監工，說以後不用下井挖煤了。我很不樂意。我決定當監工的時候也要保證挖煤時間和挖煤量，不能放棄技術。

簡單啊，不要升職就行了，這簡直是我答過的最容易的問題。

3、技術跟風，盲目崇拜所謂熱門的新瓶裝老酒的概念，譬如從前幾年的SOA到這幾年的微服務。

感覺題主這句話充滿了偏見。真正了解 SOA 就不會說這種話。如果不去客觀了解一個技術，而是簡單停留在「好、壞」「是否新潮時髦」這種標籤式的判斷上，那不就是您所反對的「跟風」么？

「老酒」若好，何懼「新瓶」！

一般代碼寫的好人，ppt都寫的不好；

ppt寫的好的人，一般代碼功力都很差。

有寫ppt的時間，不如去看書、看代碼、學習。

成為 PPT 架構師是我多年以來的夢想

首先是做人吧，踏實勤奮很重要。

如何成為架構師就不說了，如何避免成為PPT架構師還是有很多話說的。

對於很多開發人員，工作三年以後，技術沒啥大突破了。面試時候一問，都是很常規的項目經驗，技術上只是掌握會用，不了解原理。時間長了，資歷混久了，年紀也大了，很容易變成PPT架構師和嘴炮架構師。。

踏實勤奮，技術過硬，會畫圖。

硬知識：趁年輕多去研究一些技術底層細節原理，年紀大了有老婆孩子精力分散太嚴重！

軟知識：這個更難，看人領悟能力，看你對軟體工程，產品的理解了。

其實學技術，到最後慢慢會分化，全棧工程師遭黑是肯定的，不是超人無法做到面面精通。

選一個自己喜歡的技術領域，作為突破點慢慢學吧。

我覺得吧，堅持對技術的熱情是好事，但是非說堅持第一線寫代碼對於架構是非常有必要的，我覺得是對自己的時間、能力和經驗的不尊重。如果團隊（公司）需要你成為全職的架構師，就要好好去搞設計、架構，可以寫寫實驗性的代碼，跑跑benchmark，或者讀讀源碼。至於非要到第一線去親自去實現什麼功能，我覺得有點太過於做作了。

將領是不用親自去戰場拼殺的，也許他們當了將領一段時間就不會拼殺了，可是人家當將領是有理由的，將領不好好排兵布陣，底下小兵都跟著倒霉。哪個將領要是說『哎呀好久沒殺人了手癢，今天我得親自上陣』，小兵應該覺得害怕才是。

凡是那些說一段時間不寫代碼就跟最新技術脫節的，要麼是你自己想像的胡說，要麼你自己level不到，沒有領會技術背後的規律，或者說是『道』。新語言、新框架、新演算法、新模式、新架構，都是微創新，掃一眼文檔，最多看看源碼，就能get√到其中真正精妙創新的地方。人又不是神，技術都是一點一點發展的。當然基礎不好的另說。

文不對題，匿了。

不要去跟局座~~

因為他就是戰忽局出來的~~

說得難聽點叫忽悠，說得好聽點叫生態

做ppt很有講究的，做得好的肯定不是一般人，行雲流水之間你就信了，信的人多了就成了大勢