1. 從“building make more”說起一個(gè)標(biāo)題背后的工程哲學(xué)第一次看到“karpathy building make more --- 1”這個(gè)標(biāo)題我盯著屏幕愣了幾秒。它不像常規(guī)項(xiàng)目名那樣規(guī)整反而像某位工程師在深夜提交代碼時(shí)隨手敲下的備注——帶著點(diǎn)即興又藏著某種方法論。拆開來看“karpathy”指向的是一位在深度學(xué)習(xí)與工程實(shí)踐領(lǐng)域極具影響力的技術(shù)人“building”是動(dòng)詞“make more”是目標(biāo)“--- 1”則暗示這是一個(gè)系列的開篇。合在一起它傳遞的核心信號(hào)很明確用工程化的方式持續(xù)構(gòu)建、持續(xù)產(chǎn)出、持續(xù)放大。這個(gè)標(biāo)題真正吸引我的地方不在于它指向某個(gè)具體工具或框架而在于它背后那套“從零搭建、快速迭代、批量復(fù)制”的做事邏輯。我在過去幾年里做過不少類似的事情把一個(gè)臨時(shí)腳本打磨成可復(fù)用的模塊把一次性的分析流程固化成流水線把腦子里零散的想法變成能跑起來的最小原型。這個(gè)過程里踩過的坑、繞過的彎遠(yuǎn)比任何教程里寫的都多。所以這篇博文我想圍繞“building make more”這個(gè)內(nèi)核聊聊怎么把“構(gòu)建”這件事做得更系統(tǒng)、更高效、更能持續(xù)產(chǎn)出。適合誰來讀如果你手里有一堆想法卻總是停留在“想”的階段如果你寫了很多代碼但復(fù)用率低得可憐如果你做項(xiàng)目總是從零開始、每次都在重復(fù)造輪子那這篇內(nèi)容大概率能幫到你。我不打算講空泛的大道理而是把“構(gòu)建”拆成可操作的環(huán)節(jié)配上我實(shí)際用過的參數(shù)、步驟和排查思路。哪怕你剛?cè)腴T跟著走一遍也能搭出自己的第一套“產(chǎn)出系統(tǒng)”。2. 整體設(shè)計(jì)與思路拆解為什么是“構(gòu)建”而不是“堆砌”2.1 核心思路把一次性動(dòng)作變成可復(fù)用的資產(chǎn)“building make more”最容易被誤解成“多干活”。但我理解的重點(diǎn)恰恰相反不是做更多的事而是讓每一次構(gòu)建都成為下一次的起點(diǎn)。這兩者的差別就像手工打磨一個(gè)零件和設(shè)計(jì)一套模具——前者做完就沒了后者能反復(fù)產(chǎn)出。我見過太多項(xiàng)目死在“堆砌”上功能一個(gè)個(gè)往上加代碼一段段往里塞最后整個(gè)系統(tǒng)臃腫到?jīng)]人敢動(dòng)。而“構(gòu)建”的思路是先想清楚骨架再往里填血肉。具體到操作層面我通常會(huì)問自己三個(gè)問題這個(gè)模塊未來會(huì)不會(huì)被再次調(diào)用它的輸入輸出邊界是否清晰如果明天要換一個(gè)場景我需要改多少行代碼這三個(gè)問題答完方案的基本形態(tài)就出來了。以我做過的一個(gè)數(shù)據(jù)處理項(xiàng)目為例。最初的需求只是清洗一批日志寫完腳本跑通就完事了。但我判斷這類清洗邏輯后續(xù)還會(huì)反復(fù)用到于是多花了半天時(shí)間把它抽象成一個(gè)帶配置文件的處理管道輸入路徑、字段映射、過濾規(guī)則全部外置。結(jié)果第二周新來一批格式不同的日志我只改了三行配置就復(fù)用了整套邏輯。那半天的時(shí)間投入后面至少省下了三天的重復(fù)勞動(dòng)。這就是“構(gòu)建”和“堆砌”最直觀的回報(bào)差異。2.2 方案選型輕量優(yōu)先避免過度設(shè)計(jì)確定要“構(gòu)建”之后下一個(gè)問題是選什么形態(tài)。我的原則很樸素能用腳本解決的不上框架能用單文件搞定的不拆多模塊。很多人一上來就想搭一套“完整架構(gòu)”結(jié)果光目錄結(jié)構(gòu)就設(shè)計(jì)了半天真正跑起來的代碼沒幾行。這種過度設(shè)計(jì)是“make more”最大的敵人因?yàn)樗丫ο脑诹瞬划a(chǎn)生實(shí)際產(chǎn)出的地方。我通常的選型路徑是這樣的先寫一個(gè)最小可運(yùn)行版本驗(yàn)證核心邏輯跑得通然后觀察哪些部分在后續(xù)使用中被反復(fù)修改或調(diào)用只把這些部分抽出來做封裝剩下的保持原樣不為了“好看”而重構(gòu)。這個(gè)漸進(jìn)式的做法好處是每一步都有實(shí)際需求驅(qū)動(dòng)不會(huì)出現(xiàn)“設(shè)計(jì)了一套用不上的抽象層”這種尷尬。工具層面我傾向于用最基礎(chǔ)的組合一個(gè)主入口腳本負(fù)責(zé)調(diào)度若干功能函數(shù)按職責(zé)分文件存放配置統(tǒng)一走外部文件。這套組合沒有花哨的依賴換臺(tái)機(jī)器也能直接跑遷移成本極低。實(shí)測下來這種“土辦法”在中小規(guī)模項(xiàng)目里的穩(wěn)定性反而比那些重型框架高得多——因?yàn)槌鰡栴}時(shí)你能一眼看到根源在哪不用在層層封裝里大海撈針。2.3 避免的坑別讓“構(gòu)建”變成“拖延”這里必須潑一盆冷水?！皹?gòu)建”的思路很好但它有個(gè)隱蔽的陷阱容易變成拖延的借口。我見過有人為了“打好基礎(chǔ)”花兩周時(shí)間寫工具庫結(jié)果真正的業(yè)務(wù)代碼一行沒動(dòng)。這就是把手段當(dāng)成了目的。我的應(yīng)對(duì)辦法是設(shè)一個(gè)硬性約束任何基礎(chǔ)設(shè)施的構(gòu)建投入時(shí)間不超過當(dāng)次任務(wù)總時(shí)長的兩成。比如一個(gè)預(yù)計(jì)三天完成的任務(wù)我最多花半天搭腳手架剩下的時(shí)間必須用來產(chǎn)出實(shí)際結(jié)果。如果半天搭不完說明當(dāng)前階段還不需要那么復(fù)雜的基建先用最粗糙的方式跑通再說。這個(gè)約束幫我避開了無數(shù)次“基建上癮”的坑也讓“building make more”始終指向產(chǎn)出而不是停留在準(zhǔn)備階段。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)構(gòu)建系統(tǒng)的四個(gè)關(guān)鍵環(huán)節(jié)3.1 入口設(shè)計(jì)讓每次運(yùn)行都有明確的起點(diǎn)一個(gè)可復(fù)用的構(gòu)建系統(tǒng)最重要的特征是“入口清晰”。我的習(xí)慣是永遠(yuǎn)保留一個(gè)主入口文件所有功能都從這里觸發(fā)。這個(gè)文件不寫具體邏輯只負(fù)責(zé)解析參數(shù)、加載配置、調(diào)用對(duì)應(yīng)模塊。這樣做的好處是無論系統(tǒng)后來膨脹到多少個(gè)文件你始終知道從哪里開始看。主入口的參數(shù)設(shè)計(jì)有幾個(gè)細(xì)節(jié)值得注意。第一必填參數(shù)和可選參數(shù)要分開必填的放在前面且不給默認(rèn)值缺了就報(bào)錯(cuò)退出避免帶著錯(cuò)誤配置跑一半才崩。第二默認(rèn)值要選最安全的那個(gè)比如輸出路徑默認(rèn)指向一個(gè)臨時(shí)目錄而不是覆蓋原文件。第三參數(shù)命名用完整單詞別為了省幾個(gè)字符用縮寫三個(gè)月后你自己都記不住-p到底是路徑還是端口。# 主入口的典型結(jié)構(gòu)示意 import argparse from config import load_config from pipeline import run_pipeline def main(): parser argparse.ArgumentParser() parser.add_argument(--input, requiredTrue, help輸入文件路徑) parser.add_argument(--output, default./tmp/out, help輸出目錄) parser.add_argument(--config, default./config.yaml, help配置文件) args parser.parse_args() cfg load_config(args.config) run_pipeline(args.input, args.output, cfg) if __name__ __main__: main()這段結(jié)構(gòu)我用了很多次改動(dòng)很少。它的價(jià)值在于把“怎么調(diào)用”和“做什么”徹底分開了后續(xù)無論加多少功能入口的形態(tài)基本不變。3.2 配置外置把易變的部分從代碼里趕出去“make more”的關(guān)鍵在于復(fù)用而復(fù)用的最大障礙是硬編碼。我踩過最慘的一次坑是把一批閾值直接寫死在函數(shù)里結(jié)果換個(gè)場景要改十幾個(gè)地方改漏一個(gè)就出詭異結(jié)果。從那以后我強(qiáng)制自己把所有可能變化的東西都挪到配置文件里。配置外置有個(gè)度的問題。我的經(jīng)驗(yàn)是凡是跟具體數(shù)據(jù)、具體環(huán)境、具體閾值相關(guān)的一律外置凡是跟核心算法邏輯相關(guān)的留在代碼里。比如文件路徑、字段名、過濾條件、超時(shí)時(shí)間這些放配置而數(shù)據(jù)怎么轉(zhuǎn)換、結(jié)果怎么計(jì)算這些是代碼的職責(zé)。分清楚這條線配置文件就不會(huì)變成第二個(gè)代碼庫。配置文件格式我首選 YAML因?yàn)榭勺x性好、支持嵌套、注釋方便。但有個(gè)細(xì)節(jié)要注意YAML 對(duì)縮進(jìn)極其敏感一個(gè)空格錯(cuò)位就可能解析出完全不同的結(jié)構(gòu)。我的做法是在加載配置后立刻做一次結(jié)構(gòu)校驗(yàn)把關(guān)鍵字段的存在性和類型檢查一遍有問題在啟動(dòng)階段就報(bào)出來而不是等到運(yùn)行中途才炸。提示配置文件里不要放敏感信息。如果確實(shí)需要用環(huán)境變量注入配置文件里只留占位符。這個(gè)習(xí)慣能幫你避開很多后續(xù)的麻煩。3.3 模塊拆分按“變化頻率”而不是“功能類型”來分模塊怎么拆是個(gè)老生常談的問題。常見的做法是按功能分?jǐn)?shù)據(jù)處理一個(gè)模塊、結(jié)果輸出一個(gè)模塊、日志記錄一個(gè)模塊。這個(gè)分法沒錯(cuò)但我更傾向于按“變化頻率”來拆——經(jīng)常一起改的放一起很少同時(shí)改的分開。舉個(gè)例子。一個(gè)項(xiàng)目里“數(shù)據(jù)讀取”和“字段映射”幾乎每次換數(shù)據(jù)源都要一起調(diào)整那它們就該放在同一個(gè)模塊里改的時(shí)候一處改完?！敖Y(jié)果輸出”格式很穩(wěn)定半年不動(dòng)一次那就單獨(dú)放不用跟著數(shù)據(jù)層一起折騰。這種拆法的好處是每次需求變化只影響一個(gè)模塊改動(dòng)范圍可控回歸測試的范圍也小。拆完之后模塊之間的接口要盡量窄。我通常要求模塊之間只通過明確的函數(shù)調(diào)用交互不共享全局狀態(tài)。全局變量是復(fù)用的大敵因?yàn)樗屇K之間產(chǎn)生了看不見的耦合你改一個(gè)地方另一個(gè)地方莫名其妙就掛了。寧可多傳幾個(gè)參數(shù)也別圖省事用全局變量。3.4 日志與可觀測性讓問題自己浮出水面構(gòu)建系統(tǒng)跑起來之后最怕的是“出錯(cuò)了但不知道錯(cuò)在哪”。我的做法是從第一天就把日志打全而不是等出了問題再補(bǔ)。日志分三個(gè)層次入口處打一條“開始處理參數(shù)是某某”關(guān)鍵節(jié)點(diǎn)打“當(dāng)前處理到第幾步數(shù)據(jù)量多少”異常處打完整的錯(cuò)誤堆棧。這三層日志加起來排查問題時(shí)基本能還原出完整的執(zhí)行路徑。日志的粒度也有講究。打太細(xì)刷屏刷到看不清重點(diǎn)打太粗出了問題兩眼一抹黑。我的經(jīng)驗(yàn)是正常流程每個(gè)主要階段打一條循環(huán)內(nèi)部不打或只打匯總異常一律打全。比如處理一萬條數(shù)據(jù)不要每條都打日志而是每處理完一批打一條“已完成 X 條”。這樣日志量可控進(jìn)度也一目了然。import logging logging.basicConfig( levellogging.INFO, format%(asctime)s [%(levelname)s] %(message)s ) logger logging.getLogger(__name__) def process_batch(items, batch_size1000): total len(items) for i in range(0, total, batch_size): batch items[i:ibatch_size] # 處理邏輯... logger.info(已完成 %d / %d, min(ibatch_size, total), total)這段日志配置我?guī)缀趺總€(gè)項(xiàng)目都帶著改動(dòng)無非是格式和級(jí)別。它帶來的排查效率提升遠(yuǎn)比多寫幾行代碼的成本高。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)從零搭一套可復(fù)用的產(chǎn)出流程4.1 第一步定義最小可運(yùn)行閉環(huán)任何構(gòu)建都從“能跑通”開始。我的做法是先畫一條最短路徑輸入一份數(shù)據(jù)經(jīng)過最少的處理產(chǎn)出一個(gè)能看的結(jié)果。這條路徑上不追求優(yōu)雅不追求完備只追求“跑得通”。比如做文本處理最短路徑就是讀文件、按行切分、統(tǒng)計(jì)行數(shù)、打印結(jié)果。二十行代碼搞定。這一步的意義在于建立信心和基線。有了這個(gè)基線后面每加一個(gè)功能都能立刻驗(yàn)證“加了之后還跑不跑得通”。我見過不少人跳過這一步直接上手寫完整系統(tǒng)結(jié)果寫到一半發(fā)現(xiàn)某個(gè)基礎(chǔ)假設(shè)不成立前面全白費(fèi)。先跑通最小閉環(huán)相當(dāng)于先探明路況再開車穩(wěn)得多。最小閉環(huán)跑通后我會(huì)立刻把它提交到版本管理里打一個(gè)明確的標(biāo)記。這個(gè)動(dòng)作看起來瑣碎但它給了你一個(gè)“隨時(shí)可以退回”的安全點(diǎn)。后續(xù)無論怎么折騰最壞情況就是退回到這個(gè)能跑的版本心理壓力小很多反而敢做更大膽的嘗試。4.2 第二步把重復(fù)出現(xiàn)的邏輯抽成函數(shù)閉環(huán)跑通后開始觀察哪些邏輯在反復(fù)出現(xiàn)。判斷標(biāo)準(zhǔn)很簡單同樣的代碼你寫了第二遍就該抽成函數(shù)了。注意是“寫了第二遍”而不是“預(yù)計(jì)會(huì)寫第二遍”前者是實(shí)際需求后者往往是過度設(shè)計(jì)。抽取函數(shù)時(shí)我遵循一個(gè)原則函數(shù)只做一件事名字能準(zhǔn)確描述這件事。比如“讀取配置文件并解析成字典”就是一個(gè)合格的函數(shù)職責(zé)而“處理數(shù)據(jù)”這種名字就太模糊說明你還沒想清楚它到底干什么。函數(shù)參數(shù)盡量少超過五個(gè)就要考慮是不是該拆成兩個(gè)函數(shù)或者把相關(guān)參數(shù)打包成一個(gè)配置對(duì)象。抽取過程中有個(gè)容易忽略的點(diǎn)錯(cuò)誤處理要跟著一起抽。很多人在主流程里寫了 try-except抽函數(shù)時(shí)卻把異常處理留在外面導(dǎo)致函數(shù)本身很脆弱。我的習(xí)慣是讓函數(shù)對(duì)自己能預(yù)見的錯(cuò)誤負(fù)責(zé)比如文件不存在就拋一個(gè)明確的異常而不是返回 None 讓調(diào)用方去猜。這樣調(diào)用方只需要處理“意料之外”的問題邏輯清晰很多。4.3 第三步用配置驅(qū)動(dòng)不同場景當(dāng)函數(shù)抽得差不多了下一步是把“變化的部分”挪到配置里。這一步的目標(biāo)是換一個(gè)場景只改配置不改代碼。我通常從最常變的參數(shù)開始挪比如輸入路徑、輸出格式、過濾閾值。每挪一個(gè)就跑一次驗(yàn)證確保行為跟挪之前一致。配置驅(qū)動(dòng)的難點(diǎn)在于“配置的配置”——也就是配置項(xiàng)本身的結(jié)構(gòu)怎么設(shè)計(jì)。我的經(jīng)驗(yàn)是扁平優(yōu)先能用一層鍵值對(duì)解決的不搞多層嵌套。嵌套太深寫配置的人容易暈讀配置的代碼也容易出錯(cuò)。如果確實(shí)需要分組用命名前綴區(qū)分比如input_path、input_format、output_path比嵌套的input: {path: ..., format: ...}更好維護(hù)。配置項(xiàng)的數(shù)量也要控制。我見過一個(gè)配置文件寫了三百多行光看配置就得半天這種就失去了“外置”的意義。我的做法是只把真正需要頻繁調(diào)整的放配置那些一年不動(dòng)一次的常量留在代碼里反而更清楚。配置不是越多越好夠用就行。4.4 第四步加上校驗(yàn)和兜底讓系統(tǒng)能自己扛住異常系統(tǒng)能跑、能配置之后最后一步是讓它“扛得住”。這里的核心是兩件事輸入校驗(yàn)和失敗兜底。輸入校驗(yàn)是在處理之前檢查數(shù)據(jù)是否符合預(yù)期比如字段是否齊全、類型是否正確、數(shù)值是否在合理范圍。這一步能擋掉大部分“垃圾進(jìn)垃圾出”的問題。失敗兜底是指當(dāng)某個(gè)環(huán)節(jié)出錯(cuò)時(shí)系統(tǒng)不至于整個(gè)崩掉。我的做法是把處理流程分成若干獨(dú)立單元每個(gè)單元的錯(cuò)誤單獨(dú)捕獲記錄日志后繼續(xù)處理下一個(gè)。這樣一批數(shù)據(jù)里有個(gè)別壞數(shù)據(jù)不會(huì)導(dǎo)致整批失敗。當(dāng)然這個(gè)策略要看場景——如果是強(qiáng)一致性要求的場景該整體回滾就回滾不能為了“跑完”而犧牲正確性。def safe_process(item): try: return process_one(item) except Exception as e: logger.error(處理失敗: %s, 原因: %s, item.get(id), e) return None results [safe_process(item) for item in items] success [r for r in results if r is not None] logger.info(成功 %d 條失敗 %d 條, len(success), len(items) - len(success))這段兜底邏輯我?guī)缀趺總€(gè)批處理項(xiàng)目都會(huì)加。它的價(jià)值不在于“容錯(cuò)”本身而在于讓每次運(yùn)行的失敗原因都被記錄下來后續(xù)優(yōu)化有據(jù)可依。5. 常見問題與排查技巧實(shí)錄那些文檔里不會(huì)寫的坑5.1 問題速查表現(xiàn)象可能原因排查方向解決思路配置改了但不生效配置緩存未刷新 / 路徑指向錯(cuò)誤文件打印實(shí)際加載的配置內(nèi)容加載后立即輸出關(guān)鍵配置項(xiàng)處理到一半卡住某條數(shù)據(jù)觸發(fā)死循環(huán) / 外部依賴超時(shí)看最后一條日志停在哪加超時(shí)機(jī)制定位具體數(shù)據(jù)結(jié)果數(shù)量對(duì)不上過濾條件寫錯(cuò) / 重復(fù)數(shù)據(jù)未去重統(tǒng)計(jì)各階段數(shù)據(jù)量每個(gè)階段打數(shù)量日志換環(huán)境跑不通路徑硬編碼 / 依賴版本不一致對(duì)比兩邊的配置和依賴路徑全走配置鎖定依賴版本內(nèi)存越跑越高數(shù)據(jù)全量加載 / 對(duì)象未釋放觀察內(nèi)存曲線改流式處理分批釋放這張表里的每一條都是我在實(shí)際項(xiàng)目里真實(shí)遇到過的。最典型的是“結(jié)果數(shù)量對(duì)不上”十有八九是某個(gè)過濾條件把不該濾的濾掉了或者去重邏輯把不同數(shù)據(jù)當(dāng)成了重復(fù)。排查方法很土但有效在每個(gè)處理階段后面打一條數(shù)量日志看數(shù)量在哪一步開始偏離預(yù)期問題就鎖定在那一步。5.2 獨(dú)家避坑三個(gè)反直覺的經(jīng)驗(yàn)第一個(gè)經(jīng)驗(yàn)是先懷疑數(shù)據(jù)再懷疑代碼。我早期排查問題時(shí)總愛盯著代碼看覺得邏輯沒問題啊。后來發(fā)現(xiàn)八成的問題出在數(shù)據(jù)上格式不對(duì)、編碼不對(duì)、有空值、有重復(fù)?，F(xiàn)在我的第一反應(yīng)是先抽樣看幾條原始數(shù)據(jù)確認(rèn)數(shù)據(jù)本身沒問題再去查代碼。這個(gè)順序調(diào)換之后排查效率提升了一大截。第二個(gè)經(jīng)驗(yàn)是日志里一定要帶唯一標(biāo)識(shí)。處理批量數(shù)據(jù)時(shí)如果日志只寫“處理失敗”你根本不知道是哪條失敗了。我的做法是每條數(shù)據(jù)帶一個(gè) ID日志里統(tǒng)一帶上這個(gè) ID出問題時(shí)直接按 ID 搜日志整條處理鏈路一目了然。這個(gè)習(xí)慣花不了多少成本但排查時(shí)能省下大量時(shí)間。第三個(gè)經(jīng)驗(yàn)是改動(dòng)之前先跑一遍基線。每次要改核心邏輯之前我先把當(dāng)前版本跑一遍把輸出結(jié)果存下來作為基線。改完之后再跑一遍跟基線對(duì)比差異。如果差異在預(yù)期內(nèi)說明改動(dòng)沒問題如果差異超出預(yù)期說明改出了副作用。這個(gè)做法比單純看代碼 review 靠譜得多因?yàn)楹芏喔弊饔檬强床怀鰜淼闹挥信艹鰜聿努F(xiàn)形。注意基線對(duì)比時(shí)要注意輸出里的時(shí)間戳、隨機(jī)數(shù)這類每次都變的內(nèi)容對(duì)比前先過濾掉否則每次都有差異反而看不出真正的問題。5.3 性能問題的排查順序系統(tǒng)跑得慢的時(shí)候別急著優(yōu)化。我的排查順序是先看是不是數(shù)據(jù)量本身變大了再看是不是某個(gè)環(huán)節(jié)的復(fù)雜度上去了最后才看是不是有低效的寫法。這個(gè)順序很重要因?yàn)榍皟蓚€(gè)原因占了大頭而很多人一上來就盯著代碼微調(diào)調(diào)半天發(fā)現(xiàn)是數(shù)據(jù)量翻倍了白忙活。定位到具體環(huán)節(jié)后優(yōu)化也有優(yōu)先級(jí)。先優(yōu)化調(diào)用次數(shù)最多的那段代碼再優(yōu)化單次耗時(shí)最長的那段。前者是乘法效應(yīng)改一點(diǎn)全局受益后者是加法效應(yīng)改完只省那一點(diǎn)。我通常會(huì)在關(guān)鍵環(huán)節(jié)加計(jì)時(shí)日志跑一遍就知道時(shí)間花在哪了不用猜。6. 從“1”到“更多”讓構(gòu)建持續(xù)產(chǎn)生復(fù)利標(biāo)題里的“--- 1”我一直覺得很有意思。它明示這是一個(gè)系列的開端暗示后面還有 2、3、4。這恰恰是“building make more”的精髓第一次構(gòu)建的產(chǎn)出應(yīng)該成為第二次構(gòu)建的起點(diǎn)。如果每次都是從零開始那永遠(yuǎn)只是在做加法只有讓上一次的成果被下一次復(fù)用才可能產(chǎn)生復(fù)利。我在實(shí)際項(xiàng)目里的做法是每完成一個(gè)階段性構(gòu)建花半小時(shí)做一次“沉淀”把這次用到的通用邏輯整理成可復(fù)用的片段把踩過的坑記成簡短的備注把配置模板存一份。這些沉淀單獨(dú)看都很小但積累幾次之后下一個(gè)項(xiàng)目的啟動(dòng)成本會(huì)明顯下降。我現(xiàn)在的很多項(xiàng)目骨架部分基本是從之前的沉淀里拼出來的真正需要新寫的只有業(yè)務(wù)邏輯那一小塊。這個(gè)沉淀的習(xí)慣還有個(gè)副作用它會(huì)倒逼你把東西做得更通用。因?yàn)槟阒老麓芜€要用就會(huì)不自覺地考慮邊界情況、考慮參數(shù)化、考慮文檔。這種“為未來自己著想”的心態(tài)比任何代碼規(guī)范都更能提升代碼質(zhì)量。最后分享一個(gè)我一直在用的小技巧每次構(gòu)建完成后用一句話寫下“這個(gè)系統(tǒng)解決了什么問題、怎么用、有什么限制”存在項(xiàng)目根目錄的說明文件里。這句話不用長但要準(zhǔn)確。幾個(gè)月后你回頭看這一句話能幫你快速回憶起整個(gè)項(xiàng)目的脈絡(luò)比翻代碼快得多。這個(gè)習(xí)慣我堅(jiān)持了很久實(shí)測下來它是讓“構(gòu)建”真正變成“資產(chǎn)”的最簡單方式。