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