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