1. 這個標(biāo)題到底在問什么下一代軟件開發(fā)人員將是架構(gòu)師嗎——這個問題我第一次看到的時候正蹲在工位上改一個祖?zhèn)黜椖康囊蕾嚊_突。當(dāng)時我的第一反應(yīng)是別逗了我連自己寫的代碼三個月后都不想看還架構(gòu)師。但仔細琢磨了一下這個問題其實不是在問以后還需不需要寫代碼的人而是在問一個更本質(zhì)的事情當(dāng)工具的能力邊界不斷擴張軟件開發(fā)這個工種的價值重心會往哪里遷移先把話說清楚。這篇文章不是要販賣焦慮也不是要鼓吹什么程序員要完蛋了的論調(diào)。我想做的事情很具體把這個標(biāo)題背后的核心命題拆開看看它到底在討論什么、為什么會有人提出這個問題、如果真的往那個方向走一線開發(fā)者應(yīng)該怎么理解自己的位置以及現(xiàn)在可以做哪些準(zhǔn)備。適合讀這篇內(nèi)容的人寫了幾年代碼、開始思考職業(yè)縱深方向的中級開發(fā)者帶小團隊、需要做技術(shù)決策的技術(shù)負責(zé)人以及剛?cè)胄械幌胫划?dāng)API調(diào)用工程師的新人。如果你只是想知道要不要轉(zhuǎn)行那這篇可能不太適合你因為我的結(jié)論是——轉(zhuǎn)不轉(zhuǎn)行不是重點重點是你怎么定義自己每天在做的事情。這個問題的核心關(guān)鍵詞其實有三個軟件開發(fā)人員、架構(gòu)師、下一代。三個詞各有各的歧義。軟件開發(fā)人員到底指誰是寫業(yè)務(wù)代碼的還是包括測試、運維、數(shù)據(jù)工程在內(nèi)的所有工程角色架構(gòu)師是指一個title還是指一種思維方式下一代是五年后還是十年后這些不定義清楚討論就會變成各說各話。我個人的理解是這個標(biāo)題真正在問的是——當(dāng)編碼這個動作本身被越來越多的工具承接之后開發(fā)者的核心競爭力會不會從實現(xiàn)能力轉(zhuǎn)向設(shè)計能力與決策能力如果是那這種轉(zhuǎn)向意味著什么如果不是那又是什么在支撐這個判斷接下來我會從幾個層面來拆先講清楚這個判斷背后的技術(shù)背景和行業(yè)邏輯再講架構(gòu)師這個角色到底在做什么、和普通開發(fā)者的區(qū)別在哪里然后落到實操層面——如果你認同這個趨勢現(xiàn)在應(yīng)該怎么調(diào)整自己的技能結(jié)構(gòu)和日常習(xí)慣。最后會聊一些我踩過的坑和觀察到的真實情況。2. 為什么會有開發(fā)者變成架構(gòu)師這個說法2.1 工具在吃掉實現(xiàn)這件事過去十年軟件開發(fā)領(lǐng)域最大的變化不是某個語言或框架的崛起而是實現(xiàn)成本在持續(xù)下降。我剛開始寫代碼的時候搭一個帶用戶認證的Web應(yīng)用從數(shù)據(jù)庫設(shè)計到Session管理到前端表單驗證全是手寫的。現(xiàn)在呢一個全?？蚣芗右粋€認證庫半天就能跑起來。這不是因為開發(fā)者變懶了而是因為大量重復(fù)性的實現(xiàn)工作被抽象掉了。再往后看低代碼平臺、AI輔助編碼工具、自動化測試生成、基礎(chǔ)設(shè)施即代碼——這些東西的共同特點是它們把怎么寫這個問題變得越來越便宜但寫什么和為什么這么寫的問題并沒有變便宜。舉個例子。一個AI編碼助手可以幫你生成一個排序算法、一個CRUD接口、甚至一個完整的狀態(tài)管理模塊。但它沒法替你判斷這個模塊應(yīng)該放在哪一層它的邊界在哪里它和現(xiàn)有系統(tǒng)的耦合點是什么未來需求變化時這個設(shè)計會不會成為瓶頸這些判斷就是架構(gòu)層面的判斷。2.2 系統(tǒng)復(fù)雜度在上升而不是下降有人可能會說工具越強系統(tǒng)應(yīng)該越簡單才對啊。實際情況恰恰相反。工具越強我們能做的事情就越多系統(tǒng)的邊界就越往外擴。十年前一個大型系統(tǒng)可能是幾十個服務(wù)現(xiàn)在動輒上百個微服務(wù)、多個數(shù)據(jù)存儲、跨云部署、實時流處理。復(fù)雜度不是被消滅了而是被轉(zhuǎn)移了——從怎么寫代碼轉(zhuǎn)移到了怎么組織這些代碼和基礎(chǔ)設(shè)施。這就導(dǎo)致一個結(jié)果純實現(xiàn)能力的天花板在降低而設(shè)計能力和決策能力的天花板在升高。我認識一個在某公司做后端的開發(fā)者他的編碼能力非常強手寫一個高性能的緩存層不在話下。但去年他們團隊重構(gòu)的時候他發(fā)現(xiàn)自己最大的瓶頸不是寫不出來而是不知道該往哪個方向?qū)憽抢^續(xù)優(yōu)化現(xiàn)有架構(gòu)還是換一套方案換的話遷移成本怎么算不換的話未來半年的業(yè)務(wù)增長扛不扛得住這些問題沒有一個能靠寫代碼快來解決。2.3 架構(gòu)師這個角色的內(nèi)涵在變化傳統(tǒng)意義上的架構(gòu)師很多時候是一個技術(shù)權(quán)威的角色——定技術(shù)棧、畫架構(gòu)圖、評審方案。但在很多團隊里這個角色和一線開發(fā)是脫節(jié)的架構(gòu)師定了方案開發(fā)者去實現(xiàn)中間的信息損耗非常大?，F(xiàn)在越來越多團隊在嘗試另一種模式?jīng)]有獨立的架構(gòu)師崗位但每個高級開發(fā)者都需要具備架構(gòu)思維。也就是說架構(gòu)不再是一個職位而是一種能力。這就回到了標(biāo)題的問題如果架構(gòu)思維成為每個開發(fā)者的必備能力那下一代軟件開發(fā)人員將是架構(gòu)師嗎這個問題的答案可能不是是或不是而是架構(gòu)師這個title會消失但架構(gòu)能力會成為標(biāo)配。這就像全棧工程師這個概念一樣。十年前全棧是一個稀罕物現(xiàn)在雖然不是每個人都叫自己全棧但前端懂點后端、后端懂點部署已經(jīng)是很普遍的要求了。3. 架構(gòu)師到底在做什么和普通開發(fā)者的區(qū)別在哪里3.1 架構(gòu)師的核心工作不是畫圖很多人對架構(gòu)師的理解停留在畫架構(gòu)圖的人。我剛開始也這么以為直到有一次參與一個跨團隊項目的評審看到真正的架構(gòu)師是怎么工作的。那次評審會上討論的焦點不是用哪個消息隊列而是這個業(yè)務(wù)的邊界應(yīng)該怎么劃。架構(gòu)師花了大量時間在問問題這個功能的用戶是誰他們的核心訴求是什么如果這個需求明天變了哪些部分需要改哪些部分可以不動這些問題聽起來很產(chǎn)品但它們的答案直接決定了技術(shù)方案。架構(gòu)師的核心工作是在不確定的需求和確定的技術(shù)約束之間找到一個可持續(xù)的平衡點。畫圖只是這個思考過程的輸出物不是工作本身。3.2 和普通開發(fā)者的三個關(guān)鍵區(qū)別我把架構(gòu)師和普通開發(fā)者的區(qū)別歸納為三個層面第一關(guān)注的時間尺度不同。普通開發(fā)者關(guān)注的是這個迭代能不能按時交付架構(gòu)師關(guān)注的是這個設(shè)計半年后會不會成為瓶頸。這不是說普通開發(fā)者不關(guān)心未來而是他們的工作節(jié)奏決定了他們必須優(yōu)先解決眼前的問題。第二決策的不可逆程度不同。普通開發(fā)者的很多決策是可逆的——這個函數(shù)寫得不好重構(gòu)一下就行。但架構(gòu)決策往往不可逆或者逆轉(zhuǎn)成本極高——選了某個數(shù)據(jù)庫、定了某個通信協(xié)議、劃了某個服務(wù)邊界后面想改就要傷筋動骨。第三信息的廣度不同。普通開發(fā)者通常深耕一個模塊或一個技術(shù)棧架構(gòu)師需要了解從網(wǎng)絡(luò)到存儲到業(yè)務(wù)到團隊的方方面面。這不是說架構(gòu)師在每個方面都比開發(fā)者強而是他們需要知道什么時候該找誰。用一個類比來說普通開發(fā)者像是造房子的工匠架構(gòu)師像是設(shè)計房子的建筑師。工匠可以把一面墻砌得很完美但建筑師要決定這面墻放在哪里、承重多少、和門窗怎么配合。3.3 架構(gòu)能力不是升職才能獲得的這里有一個很常見的誤區(qū)很多人覺得我先寫好代碼等升到高級再學(xué)架構(gòu)。但架構(gòu)思維不是等到某個職級才突然擁有的它是在日常工作中一點點積累的。你每次決定一個函數(shù)要不要抽出來、一個模塊要不要獨立、一個接口要不要加緩存都是在做架構(gòu)決策——只是尺度小一點。我見過一些開發(fā)者代碼寫得很好但從來不關(guān)心自己寫的東西在整個系統(tǒng)里的位置。他們不知道自己的模塊被誰調(diào)用、調(diào)用頻率多高、失敗了對上游有什么影響。這種只關(guān)注自己一畝三分地的習(xí)慣時間長了就會成為瓶頸。反過來有些開發(fā)者雖然職級不高但會主動去了解上下游、去問為什么這么設(shè)計、去思考如果需求變了怎么辦。這種人往往成長得很快因為他們已經(jīng)在用架構(gòu)師的視角看問題了。4. 如果這個趨勢成立開發(fā)者應(yīng)該怎么調(diào)整4.1 從完成任務(wù)轉(zhuǎn)向理解上下文我觀察到一個現(xiàn)象很多開發(fā)者拿到需求就開始寫代碼寫完提交就完事。這種工作方式在短期內(nèi)效率很高但長期來看會限制成長。更有效的方式是在動手之前先花時間理解這個任務(wù)的上下文。這個需求是誰提的解決什么問題如果不做會怎樣做完之后會影響哪些其他模塊這些問題不需要你花很多時間但能幫你建立一種系統(tǒng)感。你會慢慢知道自己的代碼在整個系統(tǒng)中的位置也會開始理解為什么有些設(shè)計是這樣的、有些約束是必須遵守的。我自己的習(xí)慣是每接一個新任務(wù)先畫一張簡單的依賴圖——這個功能依賴誰、被誰依賴、數(shù)據(jù)怎么流。這張圖不用很精確但畫的過程就是理解上下文的過程。4.2 刻意練習(xí)決策記錄架構(gòu)決策和普通編碼決策最大的區(qū)別是架構(gòu)決策需要被記錄和解釋。我建議每個開發(fā)者都養(yǎng)成一個習(xí)慣當(dāng)你做了一個稍微重要一點的技術(shù)選擇時寫一段簡短的記錄。不用很正式幾句話就行我面臨的問題是什么我考慮了哪幾個方案我為什么選了這個這個選擇的代價是什么這個習(xí)慣的好處是第一它強迫你把思考過程外化避免憑感覺做決策第二當(dāng)你以后回頭看的時候能知道當(dāng)時的約束是什么避免用現(xiàn)在的標(biāo)準(zhǔn)去批判過去的決策第三當(dāng)你需要向別人解釋你的方案時這些記錄就是現(xiàn)成的材料。我見過很多團隊在復(fù)盤的時候吵得不可開交就是因為當(dāng)初的決策沒有記錄每個人記憶里的為什么都不一樣。4.3 學(xué)會用約束而不是技術(shù)來思考普通開發(fā)者思考問題的方式往往是用什么技術(shù)解決這個問題。架構(gòu)師思考問題的方式是在什么約束下解決這個問題。約束包括很多種時間約束、成本約束、團隊能力約束、合規(guī)約束、現(xiàn)有系統(tǒng)的約束。技術(shù)只是在這些約束下的一種選擇。舉個例子。一個團隊要做一個實時消息功能。普通開發(fā)者的第一反應(yīng)可能是用WebSocket或者用某個消息隊列。但架構(gòu)師會先問消息的實時性要求多高一秒延遲能接受嗎消息量級多大團隊里有人熟悉相關(guān)技術(shù)嗎運維成本能承受嗎這些問題的答案可能指向完全不同的方案。如果實時性要求不高輪詢可能就夠了如果團隊沒有相關(guān)經(jīng)驗用一個成熟的消息服務(wù)可能比自建更合適。學(xué)會用約束來思考意味著你不會被某個技術(shù)綁架也不會為了用新技術(shù)而用新技術(shù)。4.4 培養(yǎng)跨層的理解能力架構(gòu)能力的一個重要組成部分是跨層理解——知道從用戶點擊到數(shù)據(jù)落盤中間經(jīng)過了哪些環(huán)節(jié)。這不是要求你精通每一層而是要求你知道每一層大概在做什么、瓶頸可能在哪里、出問題的時候該往哪個方向排查。我自己的經(jīng)驗是每接觸一個新系統(tǒng)花半天時間把它的數(shù)據(jù)流和調(diào)用鏈理一遍。不用很細但要知道大概的路徑。這個習(xí)慣幫我省了很多排查問題的時間因為我知道該去哪里找線索。5. 一些常見的誤解和需要警惕的傾向5.1 架構(gòu)師不需要寫代碼這是一個非常危險的誤解。我見過一些所謂的架構(gòu)師脫離一線太久提出的方案在理論上很漂亮但落地的時候問題一大堆。好的架構(gòu)師不一定寫很多代碼但一定保持對代碼的敏感度。他們知道當(dāng)前的技術(shù)棧有什么坑、團隊的實際編碼水平如何、哪些方案看起來好但實現(xiàn)起來代價很大。如果你認同開發(fā)者會變成架構(gòu)師這個趨勢那要注意不是讓你不寫代碼而是讓你在寫代碼的同時保持對更大圖景的關(guān)注。5.2 架構(gòu)就是做抽象抽象是架構(gòu)工作的一部分但不是全部。過度抽象是很多架構(gòu)方案的常見問題——為了通用性而犧牲了可理解性最后沒人能看懂、沒人敢改。好的架構(gòu)不是最抽象的架構(gòu)而是在當(dāng)前約束下最合適的架構(gòu)。有時候一個不夠優(yōu)雅但團隊都能理解的方案比一個很優(yōu)雅但只有作者能維護的方案要好得多。5.3 只有大系統(tǒng)才需要架構(gòu)小系統(tǒng)也需要架構(gòu)只是尺度不同。一個個人項目也需要考慮代碼怎么組織、數(shù)據(jù)怎么存、以后要不要擴展。這些決策的規(guī)模小但性質(zhì)是一樣的。而且小系統(tǒng)的好處是試錯成本低。你可以在小項目里嘗試不同的架構(gòu)風(fēng)格積累經(jīng)驗等到了大項目就不會手足無措。5.4 架構(gòu)能力是天生的我不同意這個說法。架構(gòu)能力更像是一種經(jīng)驗反思的積累。你做的決策越多、復(fù)盤越多、看到的系統(tǒng)越多你的架構(gòu)判斷力就越強。當(dāng)然有些人可能天生更擅長系統(tǒng)性思考但這不代表其他人學(xué)不會。就像寫代碼一樣架構(gòu)能力也是可以刻意練習(xí)的。6. 我自己的實踐和觀察6.1 從寫得多到想得多的轉(zhuǎn)變我自己經(jīng)歷了一個明顯的轉(zhuǎn)變。剛工作那幾年我以寫得快為榮——一天能提交多少次、能完成多少任務(wù)。但后來發(fā)現(xiàn)寫得快不等于寫得好更不等于寫得對。有一次我花了兩天寫了一個功能自認為實現(xiàn)得很漂亮。結(jié)果評審的時候被問了一個問題如果這個功能的調(diào)用量增長十倍你的設(shè)計還成立嗎我當(dāng)時就愣住了因為我根本沒想過這個問題。從那以后我開始在動手之前多花時間想這個設(shè)計的假設(shè)是什么這些假設(shè)在什么情況下會不成立如果不成立代價是什么這個習(xí)慣讓我的編碼速度慢了一點但返工率大幅下降整體效率反而提高了。6.2 觀察身邊成長快的開發(fā)者我觀察到一個規(guī)律成長快的開發(fā)者往往不是編碼能力最強的而是最愿意理解為什么的。他們會問為什么這個系統(tǒng)這么設(shè)計為什么這個約束存在為什么之前的方案被放棄了這些問題看起來和眼前的任務(wù)無關(guān)但積累起來就形成了對系統(tǒng)的深層理解。這種理解在平時可能看不出差別但到了需要做決策的時候差距就出來了。有的人能快速判斷一個方案可不可行有的人只能試了才知道。6.3 一個具體的練習(xí)方法如果你認同這個方向我推薦一個具體的練習(xí)每次做完一個功能花十分鐘寫一個簡短的設(shè)計說明。內(nèi)容包括這個功能解決什么問題、我做了什么設(shè)計決策、為什么這么決策、有什么已知的局限。不用很長幾百字就行。但堅持做幾個月你會發(fā)現(xiàn)自己的思考越來越清晰表達也越來越有條理。這在需要向別人解釋方案的時候特別有用。7. 回到標(biāo)題本身下一代軟件開發(fā)人員將是架構(gòu)師嗎我的答案是下一代軟件開發(fā)人員不會都變成架構(gòu)師但架構(gòu)能力會成為區(qū)分普通開發(fā)者和優(yōu)秀開發(fā)者的關(guān)鍵分水嶺。工具在變強實現(xiàn)成本在降低這是事實。但系統(tǒng)在變復(fù)雜決策的重要性在上升這也是事實。兩件事同時發(fā)生結(jié)果就是純實現(xiàn)能力的價值在稀釋而設(shè)計能力和決策能力的價值在集中。這不是說寫代碼不重要了。代碼是架構(gòu)的落地形式?jīng)]有好的實現(xiàn)再好的設(shè)計也是空中樓閣。但如果你只會寫代碼不會思考代碼背后的結(jié)構(gòu)和權(quán)衡那你的天花板會越來越低。反過來如果你能在寫代碼的同時保持對更大圖景的關(guān)注能在做決策的時候考慮約束和代價能把自己的思考清晰地表達出來——那不管title是什么你都會是團隊里不可或缺的那個人。架構(gòu)師不是一個職位而是一種看待系統(tǒng)的方式。這種方式越早開始練習(xí)越好。