PPT架構師與寫代碼這件事兒

作者 | 王概凱

編輯 | 小智

長久以來，在軟體?程師的群體中存在?個鄙視鏈：把不寫代碼的架構師稱作「PPT 架構師」。想來這是由於在這個?業中，程序員的群體?數眾多，且「受害」?積嚴重導致的。同時從這個現象?，我也發現?家對編程和架構的理解不同。雖然?家說的都是同?個名詞，但是每個?的背景不同，所表達的含義也不同，因此造成了很多的誤解。在《聊聊架構》中對程序和架構的關係已經探討了?部分，本篇內容本來應該也是要寫的，但是當時偷了懶，最近覺得還是寫出來比較好。

在討論這個問題之前，我們最好先探討?下什麼叫寫代碼，或者叫編程 (Programming)。?在探討編程前，還需要先探討什麼叫程序 (Program)。因為編程就是編寫程序的簡稱。

很多程序員會對這?個問題嗤之以?，編程誰不懂?程序誰不懂?學個計算機語?，?這個語?來寫代碼就叫編程嘛！但是問題往往就隱藏在簡單的概念??，?們總是有意無意的忽略重要的細節，?家也不要被簡單所矇騙，就去輕視這個概念。?部分?對?常天天接觸的概念熟視無睹，不求甚解，?且說出來的時候都以為別?理解??所表達的含義。可是事實並非如此，別?只會聽懂他??有同樣理解的部分，?把不懂的部分???所理解的來代替，於是吵架就開始了。因此，我習慣於在討論問題之前，把基礎概念都梳理?遍，在這些概念定義的基礎上再展開討論，這樣就能夠避免出現模糊不清的爭論點。往往基礎概念清晰了之後，問題也?然就解開了。

程序相關的概念

什麼叫做程序呢?在本?的上下?中，程序是英?「Program」的翻譯，「Program」英?也叫「Programme」，?津詞典的解釋是「A planned series of future events or performances」。程序在中??的含義可以分作兩個字來分別解釋：「程」者，有「過程、步驟」的意思?「序」者，有「次第」的意思。合起來就是?步?步按照步驟次第發?的意思。英?和中?的含義非常接近。為什麼要按照步驟次第發?呢?因為前?個步驟結果是下?個步驟的輸入，必須等待前?步結束後，下?步才能夠開始，這就是程序。當然，在軟體?業通常都稱之為串?執?。

程序是?個無主語的名詞，凡是無主語的名詞，都是容易造成誤解的。那麼要說程序，?然必須要先明確程序的主體，這樣也就可以把程序邊界確定下來。明確了程序的主體，?然就可以明確程序的?的，即在程序中所有的步驟完成後，可以達成程序所服務的主體的某個業務?標。比如?吃飯，通過?臂獲取飯，送到嘴?咀嚼，吞咽，完成吃下??飯，再比如從吃第??飯到吃飽為?，這都是?個程序，必須每個步驟都要按順序發?。這個程序執?完成後，就達成了解決吃飯的?的飢餓問題，這就是?個業務?標。

??命周期來描述，程序也就是該主體某個業務的?命周期過程，程序的主體也就是該業務的主體。程序在執?時，如果執?該程序的主體必須、也只能是該程序的主體本身，那麼這個程序就被稱為該主體的核??命周期。如果這個程序可以交給其他的主體執?，那麼該程序則是該主體的非核??命周期，可以分?給其他主體來執?。

為什麼要分?給其他?來執?呢????，因為?在同時執?多個不同程序時，來回切換的成本太?-- 理解了這個，就能夠理解 CPU 進程切換的代價了，CPU 在同時作多任務切換時的成本與這個?樣。如果當過程序員也會有同樣體會，寫代碼的過程中被其他事情打斷後，再切回來寫代碼時，會發現前?所寫的代碼看不懂了，整個思路得重新思考、從頭開始。另???，分離出來非核??命周期，也有利於執?核??命周期，這部分在《聊聊架構》探討過，不再展開。

?旦程序交給某個主體來執?，那麼這個程序相對於原主體就變成了?個命令 (Command)。很多?對命令這個概念也是似懂非懂，因為這也是?個沒有主語的概念。其實命令就是?個主體指使某個主體完成某個程序的?個代號 (Code)，?來推動某個主體執?程序，並獲得該程序的執?的結果。

命令的執?主體也是有差別的。每個主體對?身?為的推動，也是通過命令來實現的，比如命令??的?抬起來，坐到椅?上等等，這是本地命令，執?的是?身的業務程序。當命令交給其他主體執?後，命令出現了?個新的名稱，變成從命令執?者對外提供服務的角度，把每個命令的執?稱為對外提供的服務 (Service)。

?個命令可以是?頭的，可以是書?的，可以是?個眼神，可以是?個?勢，等等等等，只要預先約定好，並且命令發起者和執?者雙?能夠理解即可。有了命令，就形成了溝通，就可以傳遞信息，就可以展開並實施分?。因此可以看到，程序由許多的命令組成，每個命令則有可能是?個?程序，可以分?給不同的主體來執?，也就形成了?個程序樹。

當然也可以說，程序就是命令，命令也是程序。最終無法可分的命令，是原?級別的命令，這是最細粒度的?作。最細粒度的?作能否再切分，取決於當前社會的技術發展?平。在計算機?業，計算機軟體的命令最細粒度，就是 CPU 的指令，?在 CPU 硬體中，?個指令的實現則需要通過給許多不同的電路元件發出命令，等等等等。

所以，什麼叫做編程呢?通過上?的討論就可以看出來，把不同的命令組合起來，形成?個程序來完成業務的?標，這個?為就叫做編程。也就是說所有?都在編程，只不過?的是?類的語??已，並不僅僅是軟體程序員能夠編程，每個?都在編程。

架構師與編程

那麼架構師和編程有什麼關係呢?主體推動??的?為、也就是命令，執?起來是很容易的，僅僅受限於?身的條件。比如對於?來講，四肢是否健全，韌帶是否柔軟等等。但是?旦要把命令交給其他的主體去執?，並仍然保持該程序的完整，這就需要架構的?持。所以架構師往往就根據這個主程序擁有者的權利和責任，對這個主程序進?分?，形成?個程序樹，並分派?權利和?責任，這就形成了?個架構，這個過程就是架構設計，也就是架構師的編程。可以看到，這整個架構設計編程過程和軟體沒有任何的關係，架構設計編程所遵循的其實就是我們所處的這個世間的規則，同樣，軟體編程也要遵從這個世界的規則、也就是架構。

回過頭來可以看到，既然命令可以??頭來表?，也可?書?的，也可以是眼神或?勢等等，那麼這些?式都可以?來編程。也就是說，只要是能夠形成?類溝通的?式，都可以?來編程。在軟體?業，我們把編程限於計算機語?，多多少少有點太窄了，因為脫離了這個世界的基礎，編程就沒有什麼意義了。更何況計算機語?是模仿?類語?的，僅僅是?類語?的?個?集，??類語?也僅僅是?類溝通?式的?集?已。

軟體程序員編程和?類的編程區別，僅僅在於程序員要把?類的程序翻譯給計算機來執?，程序員扮演的實際上是?個翻譯的角?。那麼這就要求程序員必須要同時懂得翻譯的?標語?和源語?：程序員編程的?標語?是計算機語?，源語?是業務語?，那麼就要求程序員必須同時理解業務語?和計算機的語?，也必須同時理解業務的運作機制以及計算機的運作機制。

從這個意義上說，PPT 架構師並非不編程、不寫代碼，只不過他編程所?的語?不是計算機語?罷了，他的代碼是 PPT 或者架構圖等，?的是?類語?以及業務語?，只是?PPT 來展?或運??已。?個邏輯清晰、分?明確的架構師，假設他會寫計算機代碼的話，他所寫的計算機代碼、或者說他所翻譯出來的軟體代碼，?定是結構清晰、職責明確的，同時他所說的?類語?和業務語??定也是邏輯清晰的。

因此，PPT 架構師並不是什麼可恥的事情，只要這個架構師能夠理解好業務的主程序，作出正確的分拆並落地執?，這就是?個合格的架構師。但是這並不是說所有的 PPT 架構師都是合格的架構師，就如同程序員?樣、並不是所有會寫代碼的程序員都是合格的程序員，不能夠理解業務的主程序、不能夠理解分?的架構師，甚至不能夠落地執?架構設計?案的架構師，都不是合格的架構師。

為什麼會產?這個爭論呢?

為什麼會產?這個爭論呢?背後的原因應該是因為架構師和程序員在合作的過程中，出現了?量的衝突，普遍形成了對?的局?。

這個對?的原因，???，從架構師的角度上說，基本上都是因為架構師不是領導者的角?，只能夠提供建議，並無實施的權利，所以經常會非常弱勢、縮?縮腳，也導致架構設計無法落地。可是輿論基本是?邊倒的傾向，都覺得架構師是有問題，為什麼沒有聽到架構師的觀點呢?想來是因為程序員群體的體量太?，?架構師的體量太?，因此架構師圈?的聲?相對會?很多。

有?會挑戰說，如果架構師是?個領導者的角?，不就又會出現「屁股決定腦袋」、並瞎指揮的情況嗎?在?常?活中，只有對結果不必負責任、並且有決定權利的領導者，才會出現這種情況。如果達到權責對等，那麼這個領導者?定會深思他所作的決定，他不會去損害??的利益，他做出的決定?定是對??有利的。假設他給下屬挖坑，那麼最終影響的還是他??的利益，他不會?這種事的。如果他不需要對坑負責，那麼他就隨便挖了。有些架構師沒有責任感，也有?法逃避責任，並且只知道邀功的話，那麼坑就多了。很多公司不信任架構師，其實就在於架構師的責權不清，無法追責，出了問題是其他?背鍋。其實不僅僅是架構師，任何職位都是這樣，責任權利不對等，就會出事。?員職責不清，軟體系統?然也是職責不清，?塌糊塗。

也有?說，架構師是?個角?，不是?個職位。如果架構師不是?個職位，那麼他就沒有相應的權利，?然就無法落地他的架構。如果架構師不是?個職位，那麼他不必承擔整個系統的責任，可是他又有權利去做系統的架構改變的時候，那麼可以想像，這個團隊?定會遇到很多因此?導致的困難，因為架構師可以盡情的去嘗試他??的想法?不必擔?負責任，因為最終系統的責任是由團隊的領導者來承擔的，?架構師的簡歷則可以寫的很漂亮。當然也有?種情況，架構師同時具備影響?，有能?去影響架構，雖然他不必承擔責任，但是這個架構師具備極強的責任感，那他也是可以把事情做好的，這類架構師應該是現在各家公司夢寐以求的?才吧。可是這類?太少了，吃的是草，擠出來的是奶，損害的是他??的利益，也是無法長久的。因此，僅靠影響?，架構師很難玩轉，即便有些?可以這麼做，那麼也?定是很累的，投入產出會相差很?。最省?的辦法就是做到權責對等，這樣才能夠達到雙贏。

另???，則要從程序員的特質來探討，可能有?個??的因素。

???，可能是因為?家經常拿建築來類比，把程序員類比為泥瓦?，太傷感情了，其實這個類比不準確，程序員可以類比為?個翻譯官。類比的錯誤，就會導致很多架構師輕視程序員的?作，從?拔???的?作。其實?們都有拔???的所崇尚的職業的傾向，?實際上?家只是分?不同?已。那麼對於程序員??，作為?個翻譯官，如果不能夠很好的??類語?來編程，那麼要做到?計算機語?能夠很好的編程，這是很難的事情。我想，這應該是很多?都忽略的地?，這對程序員的素質是?個很?的要求，這個要求?點都不低。去看看翻譯官的?作，必須要深入到被翻譯的領域中去，並通曉兩種不同的語?，要做好是非常困難的。

再?個，從程序員本身的利益來考慮，對語?掌握的精通，對技術的掌握的多少，這是當前?業對程序員?平的?個評價，體現在每個程序員的個?簡歷上。因為這個比較容易打動僱主，也容易得到驗證。?家也會發現，這個和翻譯官追求精通掌握的語?要多是?樣的道理。?架構師的出現，會平衡業務和技術，以求最合適最穩妥的落地?案，因此往往不會冒險采?最新潮的技術，而這就挑戰了程序員的個?技術積累，因為這樣會讓程序員很難?上他??想學的最新技術。同時，程序員是?個?智商的群體，通常都?視甚?，來了?個對??指?畫腳的架構師，卻甚至不會寫代碼、或所寫的代碼??都看不上，難免會出現敵對的情緒。?通常這個架構師會更偏向於業務，和業務?的比較近，會讓程序員覺得架構師靠忽悠領導混飯吃，?拿程序員做炮灰。所以程序員第?反應是，架構師代碼都沒我寫的好，還來指揮我寫代碼，架構師所設計的?案，從技術角度來看，那就更看不上了。如此，不起衝突反?是很難的事情。

其實在架構師的圈??，也同樣會有操?架構無法落地，程序員不聽指揮等等的問題。這也就是為什麼我認為架構師必須要對架構落地全?負責，不能僅僅當軍師，或者僅僅靠影響?，因為權利和責任不對等，是很難做好?作的。這也是為什麼要探討「架構師是做什麼的」、「架構是什麼」，這個不搞清，程序員和架構師就無法很好的進?合作。只有搞清楚了各?的職責，才能夠互相協助、互相?持，達到共贏 ---- 業務飛速的成長。

程序員學習業務的重要性

還有?部分程序員會有疑惑：業務不就是做些 CRUD 嘛，沒什麼意思，我做的是技術框架，不需要和業務打交道。

只要是需要記憶?戶狀態的應?，都是需要 CRUD 的，這沒有什麼問題。可是把業務和 CRUD 等同，只能說是對業務理解的不夠，並且其所寫的代碼，業務邏輯?定會分散到資料庫和訪問代碼中，這個項?成長的過程中?定會遇到比較?的危機。這部分內容，《聊聊架構》中已經探討過，也就不展開了。

如果做的是技術框架，就真的不需要和業務打交道嗎?比?說學習演算法，如果不知道演算法的業務場景，這個演算法是學不好的。比如排序演算法，無非就是把現實空間的問題，?數學代號表?出來，因此演算法離不開分治 (Divide and Conquer)，所分出來最有效的就是?棵樹，因為空間的切分，是不允許有重合的。也可以發現，這不但和演算法的業務有關，和架構也有關係。當我們把演算法中的非核?過程交給其他進程或 CPU 來執?，這就可以形成並?，??縮減計算所需要的時間，這其實就是架構。

再比如設計?個?關，如果不理解?關所?對的業務，任何?無法憑空想像出來?個?關如何做。很多?投入精?學習 OSGi，可是在互聯?為何不流?呢?這是因為伺服器是可以橫向擴展的，做成不同的服務來發布，比單純的?個 APP 中的模塊化成本更低。反?在終端設備上，由於硬體無法擴張，應?又需要模塊化的話，OSGi 就能派上?場了。這些都是業務。投入學習?個技術，必須要先理解這個技術的業務背景，這樣才能夠有的放?，也會少踩坑。

哪怕去學習操作系統，那麼多的設備需要管理，要做好這?塊，需要?夠的設備管理業務知識儲備，那麼多的?件需要管理，需要?夠的?件管理業務知識儲備，等等等等。很多?學習計算機的專業知識，往往不得要領，原因即是在此，因為不懂得技術背後的業務。我經常開玩笑說，食堂?的清潔阿姨都比我們的很多程序員都更懂內存的垃圾回收策略。比如每個?吃完了，盤?是阿姨負責收的還是每個???把吃飯盤收?的?這是兩種不同的模式。那麼為什麼不是所有食堂都要求每個???帶?垃圾呢?這似乎是更?素質的?為啊，為何計算機不採?呢?這個問題提出來就很好了，這是標準的業務問題。如果是阿姨負責收的話，這是我們通常的垃圾回收場景，阿姨是怎麼做到以最?的代價，最快的收拾空餘座位的盤?的呢?如果多個阿姨?起來收，她們是怎麼互相協調的呢??個位?的盤?還沒有收，有?等在旁邊要坐，怎麼辦呢?要做 VM 的垃圾回收策略的開發，這?就是最好的業務學習場景。

在食堂?經常會有盤?架，?般都會最少放兩個，?個裝滿後，食堂收拾的師傅就會拉??個，並換上?個空的，同時也不耽誤?家，?家可以繼續把吃完的盤?放在另?個盤?架上，這就是典型的雙緩衝策略。那麼食堂的師傅當然也比很多程序員更懂得雙緩衝，儘管他不懂如何軟體編程，但是他可以指導程序員如何寫雙緩衝，因為他更懂雙緩衝的業務、雙緩衝可以讓?產者和消費者互不影響。

看到這?，我們還可以說程序員不需要懂業務嗎?恰恰是越懂業務，代碼寫得越好，不管是在計算機領域，還是在業務領域，都是如此的，只不過?家把計算機領域的不認為是業務罷了，以為只是技術，其實也是業務。?家千萬不要看不起業務，業務學好了，計算機技術才可以學好。

程序員眼中的架構師

程序員往往認為設計技術框架的?才是架構師，或是很?的程序員，這也是程序員鄙視 PPT 架構師的原因之?。確實是有很多設計技術框架的?是架構師，因為他掌握了技術框架背後的業務，並進?合理的分拆，形成不同的分?，組織?家?起完成，這就是架構師所?的事情，並且他具有資源調動的權利，可以落地實施他的架構設計。但是不是所有設計框架的?都是架構師，很多?不過是把別?的設計拿過來改改，以適合??的場景罷了，也不具備資源落地他??的架構設計，這類的不屬於架構師。

那麼很?的程序員是不是架構師呢?那就要看這個「?」怎麼來定義了，不同的?眼中的「?」法不?樣。有些?認為那些技術框架玩的很熟的?很?，這類就很難符合本?中的架構師定義了，?且技術更新換代太快，很快他們就會遇到瓶頸。有些?把團隊中的救?隊員稱為架構師，認為他們很?，往往這類?是團隊中最?苦的那個。?個團隊?但開始依賴救?隊員，那麼這個團隊的?會越冒越多，救?隊員也會遇到瓶頸，他的知識也很難得到傳遞，變成惡性循環。之所以他會成為救?隊員，?定是因為他無法在研發過程中落地實施他的想法，迫使他只能夠在事後來解決，?然他也無法成為架構師。

程序員到架構師

既然架構師主要是??類語?和業務語?來寫代碼，當然也有?部分架構師也具備寫軟體代碼的能?，因為對於很多?來講，多學?門語?並不是難事。反過來，軟體程序員未來?定能夠成為架構師嗎?這是軟體?業的晉陞路線圖之?，許多軟體程序員把??的?標定位為成為架構師。從前?討論的結果來看，這就好比問，翻譯官可以成為架構師嗎?這完全是兩種不同的?業，所解決的問題完全不同，不具備可比性。?程序員要成為架構師的話，那就相當於改?了，或者說轉型。當然此處的架構師也並非?家平常所指的資深的代碼?員，或者是軟體開發團隊中能?超強的救?隊員。

程序員可以成為架構師，因為任何?都可以成為架構師。程序員也並不必?定要成為架構師，但是要成為?個好的程序員，最起碼要能夠成為??所寫程序的架構師。?要成為??程序的架構師，就要理解??程序中的訪問代碼和業務代碼的切分，做好??代碼的分?。如果做到這?點，代碼就不會差了。做好了對???作的分?，?先就成了???作的架構師。如果想要轉型架構師，就再進?步去了解業務的架構。接觸的業務多了，就可以慢慢成為某個業務的領導者，可以去負責這個業務的架構，包括這個業務的軟體架構，融合業務及軟體於?身，負責對業務或軟體團隊的分?，這就是?個合格的軟體架構師，因為不能夠落地的架構師，不是真正的架構師。當然?們經常會說，這是在往管理的?向發展，可是不具備調動資源能?，又怎麼能做好架構師?作呢?！

真正?的程序員，是以很少的代碼達到?的的?，是每天可以?效完成代碼，不會經常有線上問題的?，是每天能夠按時上下班的?。他不?定要成為架構師，但是他?定是具備架構師思維的，他能夠合理拆分他??所寫的代碼。不要因為?家?看架構師，就看不起程序員，其實程序員本身就是?個了不起的職業。

專欄推薦

極客時間《從 0 開始學架構》專欄，目前專欄已有 2.6W+ 技術人訂閱。50 期課程中，資深技術專家李運華從架構基礎、三大架構模式和實戰的角度，分享他近 10 年從業經歷積累的一整套架構設計方法論。目前已經全部更新完，你學習後能快速理解陌生的架構設計，對架構設計遊刃有餘，照著做你也能成為架構師。

現在訂閱，還有以下福利：

福利一：訂閱專欄，一次性獲得專欄全集，附贈《架構師成長技能圖譜》一份

福利二：老用戶每邀請一位好友購買，可以獲得 24 元現金返現，上不封頂，立即提現。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！