1. 從t3code這個(gè)標(biāo)題說起一個(gè)輕量級(jí)代碼工具的設(shè)計(jì)思路第一次看到t3code這個(gè)名字直覺告訴我這是一個(gè)跟代碼打交道的工具而且t3這個(gè)前綴大概率不是隨便起的——要么是某個(gè)技術(shù)棧的縮寫要么是版本代號(hào)要么是某種極簡主義的命名哲學(xué)。我拿到這個(gè)標(biāo)題之后沒有急著去猜它具體是什么而是先想清楚一件事一個(gè)以code為核心詞的項(xiàng)目它到底解決的是哪一類問題是代碼生成、代碼格式化、代碼片段管理還是某種編碼轉(zhuǎn)換工具從命名習(xí)慣來看t3這種短前綴在開發(fā)者社區(qū)里通常意味著輕量快速第三版或者某個(gè)技術(shù)組合的縮寫。結(jié)合code這個(gè)后綴我傾向于把它理解為一個(gè)面向開發(fā)者的輕量級(jí)代碼處理工具核心能力圍繞代碼的生成、轉(zhuǎn)換、組織或管理展開。這類工具在當(dāng)下的開發(fā)環(huán)境里需求非常明確開發(fā)者每天要處理大量重復(fù)性的代碼片段、模板、配置如果每次都手動(dòng)寫效率極低且容易出錯(cuò)。一個(gè)趁手的代碼工具能把這些重復(fù)勞動(dòng)壓縮到幾秒鐘。這篇文章我想聊的不是某個(gè)具體產(chǎn)品的說明書而是圍繞t3code這個(gè)標(biāo)題所代表的一類工具把它的設(shè)計(jì)邏輯、核心實(shí)現(xiàn)、實(shí)操細(xì)節(jié)和踩坑經(jīng)驗(yàn)完整拆開講一遍。適合誰看如果你是一個(gè)經(jīng)常寫代碼、做項(xiàng)目、需要管理大量代碼片段的開發(fā)者或者你正在考慮自己做一個(gè)類似的代碼工具那這篇內(nèi)容應(yīng)該能給你不少參考。我會(huì)盡量用從業(yè)者之間聊天的口吻把每個(gè)技術(shù)選擇背后的為什么講清楚而不是只丟一堆結(jié)論。2. 核心設(shè)計(jì)拆解t3code這類工具到底該怎么架構(gòu)2.1 為什么輕量級(jí)代碼工具要優(yōu)先考慮零依賴做任何工具第一個(gè)要回答的問題都是它跑在什么環(huán)境里對(duì)于t3code這類代碼處理工具我的第一原則是盡量做到零依賴或者極少依賴。原因很實(shí)際開發(fā)者本機(jī)的環(huán)境千差萬別Node版本、Python版本、系統(tǒng)架構(gòu)都不一樣。如果你的工具依賴一大堆第三方庫用戶光裝環(huán)境就要折騰半小時(shí)那這個(gè)工具的使用率會(huì)斷崖式下跌。我試過很多類似的工具最后發(fā)現(xiàn)一個(gè)規(guī)律凡是安裝步驟超過三步的基本都會(huì)被棄用。所以t3code在設(shè)計(jì)上如果是命令行工具優(yōu)先用標(biāo)準(zhǔn)庫實(shí)現(xiàn)核心邏輯如果是Web工具優(yōu)先用原生API而不是重型框架。舉個(gè)例子如果要做代碼片段的語法高亮與其引入一個(gè)幾百KB的高亮庫不如針對(duì)常用語言寫一個(gè)輕量的正則匹配方案雖然覆蓋面窄一點(diǎn)但啟動(dòng)速度和包體積的優(yōu)勢(shì)非常明顯。當(dāng)然零依賴不等于功能殘缺。這里的取舍邏輯是核心功能必須自包含邊緣功能可以按需加載。比如代碼解析、模板替換、文件讀寫這些核心能力用標(biāo)準(zhǔn)庫就能搞定而像代碼格式化、復(fù)雜語法分析這種重活可以做成可選插件用戶需要的時(shí)候再裝。2.2 代碼工具的核心抽象把代碼當(dāng)成數(shù)據(jù)來處理t3code這類工具最關(guān)鍵的思維轉(zhuǎn)變是把代碼從文本提升為結(jié)構(gòu)化數(shù)據(jù)。很多人寫代碼工具的時(shí)候習(xí)慣用字符串拼接、正則替換來處理代碼短期看沒問題但一旦邏輯復(fù)雜起來就會(huì)陷入正則地獄——改一個(gè)地方崩三個(gè)地方。我的做法是先定義代碼的數(shù)據(jù)模型再寫處理邏輯。具體來說一段代碼可以被抽象成幾個(gè)層次層次內(nèi)容處理方式字符層原始文本讀寫、編碼轉(zhuǎn)換行層按行分割行號(hào)定位、增刪行塊層函數(shù)、類、代碼塊縮進(jìn)分析、括號(hào)匹配語義層變量、調(diào)用關(guān)系A(chǔ)ST解析可選對(duì)于t3code這種輕量工具做到塊層就夠用了。塊層的核心是縮進(jìn)和括號(hào)的配對(duì)分析這兩個(gè)信息能讓你在不引入完整解析器的情況下實(shí)現(xiàn)大部分代碼操作需求。比如你要在某個(gè)函數(shù)末尾插入一段代碼只需要找到函數(shù)起始行然后向后掃描縮進(jìn)層級(jí)找到函數(shù)結(jié)束的位置插入即可。這個(gè)邏輯用幾十行代碼就能寫出來比引入一個(gè)完整的AST解析器輕得多。2.3 命名里的t3版本化思維與迭代策略雖然我不確定t3code里的t3具體指什么但從工程角度講這種命名方式本身就傳遞了一個(gè)信號(hào)這個(gè)項(xiàng)目是有版本演進(jìn)規(guī)劃的。我在做自己的工具時(shí)也習(xí)慣在命名里留出版本空間因?yàn)榇a工具這類東西第一版永遠(yuǎn)不可能完美后續(xù)一定會(huì)根據(jù)使用反饋不斷調(diào)整。版本化思維體現(xiàn)在兩個(gè)層面。第一是接口的穩(wěn)定性核心命令和參數(shù)一旦定下來后續(xù)版本盡量保持兼容不能今天叫g(shù)en明天叫g(shù)enerate用戶會(huì)瘋掉。第二是功能的漸進(jìn)增強(qiáng)第一版只做最核心的代碼生成第二版加模板管理第三版加批量處理每一步都建立在前一步穩(wěn)定的基礎(chǔ)上。這里有個(gè)實(shí)操心得在項(xiàng)目初期就把配置文件的結(jié)構(gòu)定好哪怕很多字段暫時(shí)用不上。因?yàn)榕渲梦募怯脩艚佑|最多的東西一旦結(jié)構(gòu)變了所有用戶的配置都要遷移成本極高。我一般會(huì)在配置文件里預(yù)留一個(gè)version字段后續(xù)做遷移的時(shí)候就有依據(jù)了。3. 核心功能實(shí)現(xiàn)從代碼生成到片段管理的完整鏈路3.1 模板引擎的選型與實(shí)現(xiàn)細(xì)節(jié)t3code這類工具最常用的功能就是基于模板生成代碼。比如你有一個(gè)項(xiàng)目腳手架需要根據(jù)用戶輸入的項(xiàng)目名、作者、技術(shù)棧生成一堆配置文件。這個(gè)場(chǎng)景下模板引擎的選擇直接決定了工具的易用性。我對(duì)比過幾種方案字符串替換最簡單{{name}}直接替換成變量值。優(yōu)點(diǎn)是零依賴、速度快缺點(diǎn)是無法處理?xiàng)l件邏輯和循環(huán)。輕量模板引擎支持if、for等基本邏輯代碼量在幾百行左右可以自己實(shí)現(xiàn)或者引入一個(gè)極小的庫。完整模板引擎功能強(qiáng)大但體積大對(duì)于代碼生成場(chǎng)景來說往往過度設(shè)計(jì)。我的建議是如果只是做簡單的變量替換字符串替換就夠了如果需要根據(jù)技術(shù)棧生成不同的文件結(jié)構(gòu)那就上一個(gè)輕量模板引擎。具體實(shí)現(xiàn)上我傾向于自己寫一個(gè)簡單的模板解析器核心邏輯就是掃描模板文本遇到{{就開始解析表達(dá)式遇到}}就結(jié)束中間的內(nèi)容根據(jù)類型做不同處理。# 一個(gè)極簡模板替換的核心邏輯示意 import re def render(template, context): def replace(match): key match.group(1).strip() return str(context.get(key, match.group(0))) return re.sub(r\{\{(.?)\}\}, replace, template)這段代碼雖然簡單但已經(jīng)能覆蓋80%的代碼生成場(chǎng)景。如果要支持條件邏輯可以在此基礎(chǔ)上擴(kuò)展比如識(shí)別{% if %}這樣的標(biāo)記做塊級(jí)處理。關(guān)鍵是要控制復(fù)雜度不要為了1%的需求把整個(gè)模板引擎搞得無比龐大。3.2 代碼片段的存儲(chǔ)與檢索方案代碼工具的另一個(gè)核心能力是片段管理。開發(fā)者經(jīng)常需要保存一些常用的代碼片段比如數(shù)據(jù)庫連接配置、日志初始化代碼、常用的工具函數(shù)等。t3code如果要做這個(gè)功能存儲(chǔ)方案的選擇很關(guān)鍵。我試過幾種方案各有優(yōu)劣方案優(yōu)點(diǎn)缺點(diǎn)適用場(chǎng)景純文本文件簡單、可版本控制檢索慢、無結(jié)構(gòu)片段數(shù)量少JSON文件結(jié)構(gòu)清晰、易讀寫大文件性能差中等規(guī)模SQLite檢索快、支持復(fù)雜查詢需要額外依賴大規(guī)模片段內(nèi)存持久化速度快實(shí)現(xiàn)復(fù)雜高頻訪問對(duì)于t3code這種輕量工具我推薦JSON文件內(nèi)存索引的方案。啟動(dòng)時(shí)把JSON加載到內(nèi)存建立一個(gè)簡單的倒排索引關(guān)鍵詞到片段ID的映射檢索的時(shí)候直接查內(nèi)存。寫入的時(shí)候更新內(nèi)存并異步落盤。這樣既保證了速度又保持了數(shù)據(jù)的可讀性和可遷移性。具體實(shí)現(xiàn)上每個(gè)片段可以包含這些字段id、title、language、tags、content、created_at、updated_at。檢索的時(shí)候支持按標(biāo)簽過濾、按語言過濾、按關(guān)鍵詞模糊匹配。這里有個(gè)細(xì)節(jié)標(biāo)簽的設(shè)計(jì)要克制不要搞太多層級(jí)扁平化的標(biāo)簽體系最實(shí)用。我見過一些工具搞了多級(jí)分類結(jié)果用戶根本懶得維護(hù)最后都變成了未分類。3.3 批量處理與自動(dòng)化集成單個(gè)片段的生成和管理只是基礎(chǔ)t3code真正體現(xiàn)價(jià)值的地方在于批量處理和自動(dòng)化集成。比如你有一個(gè)項(xiàng)目需要生成20個(gè)相似的配置文件每個(gè)文件的差異只是幾個(gè)參數(shù)這時(shí)候批量處理就能省下大量時(shí)間。批量處理的核心是數(shù)據(jù)源模板輸出規(guī)則的三元組。數(shù)據(jù)源可以是一個(gè)CSV文件、一個(gè)JSON數(shù)組或者命令行傳入的參數(shù)列表模板就是前面說的代碼模板輸出規(guī)則定義了每個(gè)生成結(jié)果寫到哪個(gè)文件。實(shí)現(xiàn)上就是遍歷數(shù)據(jù)源對(duì)每條數(shù)據(jù)渲染模板然后按規(guī)則寫文件。# 批量生成的命令示意 t3code batch --data projects.csv --template config.tpl --output ./configs/{name}.json自動(dòng)化集成方面t3code可以做成一個(gè)可以被其他工具調(diào)用的命令行程序也可以提供一個(gè)簡單的HTTP接口。我的經(jīng)驗(yàn)是命令行優(yōu)先HTTP接口按需。因?yàn)槊钚懈菀准傻紺I/CD流程里也更容易調(diào)試。HTTP接口雖然靈活但引入了網(wǎng)絡(luò)層的復(fù)雜性對(duì)于本地工具來說往往是過度設(shè)計(jì)。4. 實(shí)操全流程從零搭建一個(gè)t3code風(fēng)格的工具4.1 環(huán)境準(zhǔn)備與項(xiàng)目初始化假設(shè)我們要從零做一個(gè)t3code風(fēng)格的工具第一步是確定技術(shù)棧。我的選擇是Python 標(biāo)準(zhǔn)庫原因很簡單Python在文本處理方面生態(tài)成熟標(biāo)準(zhǔn)庫足夠強(qiáng)大而且跨平臺(tái)。如果你更熟悉Node.js用Node做也完全沒問題思路是一樣的。項(xiàng)目初始化的時(shí)候目錄結(jié)構(gòu)要提前規(guī)劃好t3code/ ├── t3code/ │ ├── __init__.py │ ├── cli.py # 命令行入口 │ ├── core/ │ │ ├── template.py # 模板引擎 │ │ ├── snippet.py # 片段管理 │ │ └── batch.py # 批量處理 │ └── utils/ │ ├── file.py # 文件操作 │ └── index.py # 索引管理 ├── tests/ ├── templates/ # 內(nèi)置模板 └── README.md這個(gè)結(jié)構(gòu)的好處是職責(zé)清晰core目錄放核心邏輯utils放通用工具cli只負(fù)責(zé)參數(shù)解析和命令分發(fā)。后續(xù)要加新功能只需要在core里加模塊不會(huì)影響其他部分。初始化的時(shí)候還要做一件事定義配置文件的位置和格式。我一般放在用戶目錄下的.t3code/config.json格式用JSON包含默認(rèn)模板路徑、片段存儲(chǔ)路徑、日志級(jí)別等配置。第一次運(yùn)行的時(shí)候如果配置文件不存在就自動(dòng)生成一份默認(rèn)配置。4.2 核心命令的實(shí)現(xiàn)與參數(shù)設(shè)計(jì)t3code的命令設(shè)計(jì)要遵循動(dòng)詞名詞的原則讓用戶一看就知道是干什么的。我設(shè)計(jì)了幾個(gè)核心命令t3code gen生成代碼參數(shù)包括--template、--output、--var變量鍵值對(duì)t3code snippet add/list/search/remove片段管理t3code batch批量處理t3code init初始化項(xiàng)目配置參數(shù)設(shè)計(jì)上有個(gè)原則必填參數(shù)用位置參數(shù)可選參數(shù)用選項(xiàng)。比如t3code gen template.tpl模板文件是必填的用位置參數(shù)--output是可選的默認(rèn)輸出到標(biāo)準(zhǔn)輸出。這樣用戶用起來最自然。# 命令行入口的核心邏輯示意 import argparse def main(): parser argparse.ArgumentParser(progt3code) subparsers parser.add_subparsers(destcommand) gen_parser subparsers.add_parser(gen, help生成代碼) gen_parser.add_argument(template, help模板文件路徑) gen_parser.add_argument(--output, -o, help輸出文件路徑) gen_parser.add_argument(--var, -v, actionappend, help變量格式keyvalue) args parser.parse_args() # 后續(xù)分發(fā)到對(duì)應(yīng)的處理函數(shù)這里有個(gè)實(shí)操細(xì)節(jié)--var參數(shù)用actionappend允許用戶傳多個(gè)變量。比如-v nametest -v authorme解析出來就是一個(gè)列表再轉(zhuǎn)換成字典。這比讓用戶傳一個(gè)JSON字符串友好得多。4.3 模板渲染的完整實(shí)現(xiàn)過程模板渲染是t3code的核心我把實(shí)現(xiàn)過程拆成幾步第一步讀取模板文件。這里要注意編碼問題統(tǒng)一用UTF-8讀取避免中文亂碼。如果文件不存在給出明確的錯(cuò)誤提示而不是拋一個(gè)看不懂的異常。第二步解析變量。從命令行參數(shù)和配置文件中收集變量命令行參數(shù)的優(yōu)先級(jí)高于配置文件。變量名統(tǒng)一轉(zhuǎn)成字符串處理避免類型問題。第三步渲染。用前面說的正則替換方案把{{var}}替換成實(shí)際值。如果變量不存在保留原樣還是替換成空字符串我的選擇是保留原樣并給出警告這樣用戶能發(fā)現(xiàn)自己的變量名寫錯(cuò)了而不是生成一個(gè)缺了內(nèi)容的文件。第四步輸出。如果指定了--output就寫到文件否則打印到標(biāo)準(zhǔn)輸出。寫文件的時(shí)候要自動(dòng)創(chuàng)建父目錄避免因?yàn)槟夸洸淮嬖诙　ef render_template(template_path, variables): with open(template_path, r, encodingutf-8) as f: content f.read() missing [] def replace(match): key match.group(1).strip() if key in variables: return str(variables[key]) missing.append(key) return match.group(0) result re.sub(r\{\{(.?)\}\}, replace, content) if missing: print(f警告以下變量未定義{, .join(set(missing))}) return result這段代碼雖然不長但包含了幾個(gè)關(guān)鍵設(shè)計(jì)編碼統(tǒng)一、缺失變量警告、保留原樣。這些都是實(shí)際使用中總結(jié)出來的經(jīng)驗(yàn)看起來是小細(xì)節(jié)但直接影響用戶體驗(yàn)。4.4 片段管理的增刪改查實(shí)操片段管理的實(shí)現(xiàn)相對(duì)直接核心就是讀寫JSON文件內(nèi)存索引。我以添加片段為例走一遍完整流程用戶執(zhí)行t3code snippet add --title 數(shù)據(jù)庫連接 --language python --tags db,config --file conn.py工具要做這幾件事讀取conn.py的內(nèi)容生成一個(gè)唯一ID可以用時(shí)間戳隨機(jī)數(shù)或者UUID構(gòu)造片段對(duì)象包含標(biāo)題、語言、標(biāo)簽、內(nèi)容、創(chuàng)建時(shí)間追加到JSON文件更新內(nèi)存索引檢索的時(shí)候用戶執(zhí)行t3code snippet search --tag db工具從內(nèi)存索引里找到所有帶db標(biāo)簽的片段按更新時(shí)間排序輸出。這里有個(gè)優(yōu)化點(diǎn)索引在啟動(dòng)時(shí)構(gòu)建一次后續(xù)寫入時(shí)增量更新避免每次檢索都重新掃描整個(gè)文件。class SnippetManager: def __init__(self, store_path): self.store_path store_path self.snippets self._load() self.index self._build_index() def _build_index(self): index {} for snippet in self.snippets: for tag in snippet.get(tags, []): index.setdefault(tag, []).append(snippet[id]) return index def add(self, title, language, tags, content): snippet { id: str(uuid.uuid4()), title: title, language: language, tags: tags, content: content, created_at: time.time() } self.snippets.append(snippet) for tag in tags: self.index.setdefault(tag, []).append(snippet[id]) self._save() return snippet[id]這個(gè)實(shí)現(xiàn)里ID用UUID而不是自增數(shù)字是為了避免多設(shè)備同步時(shí)的沖突。雖然t3code目前是本地工具但留好擴(kuò)展空間總沒錯(cuò)。5. 常見問題與排查技巧實(shí)錄5.1 模板渲染中的編碼與轉(zhuǎn)義問題實(shí)際操作中編碼問題是最常見的坑。我遇到過幾次這樣的情況模板文件在Windows上編輯保存默認(rèn)用了GBK編碼到了Linux上讀取就亂碼。解決辦法是在讀取文件時(shí)顯式指定編碼并且在文檔里明確要求模板文件用UTF-8保存。另一個(gè)坑是轉(zhuǎn)義。如果模板內(nèi)容里本身就有{{這樣的字符比如Vue模板就會(huì)被誤認(rèn)為是變量標(biāo)記。解決辦法是提供一個(gè)轉(zhuǎn)義語法比如\{{表示字面量。實(shí)現(xiàn)上在正則替換之前先把\{{替換成一個(gè)占位符渲染完成后再替換回來。提示模板文件統(tǒng)一用UTF-8編碼保存如果內(nèi)容里包含{{字面量用\{{轉(zhuǎn)義。5.2 批量處理時(shí)的路徑與權(quán)限問題批量處理最容易出問題的地方是輸出路徑。用戶傳進(jìn)來的路徑可能是相對(duì)路徑、絕對(duì)路徑或者包含~的路徑。我的處理方式是統(tǒng)一轉(zhuǎn)換成絕對(duì)路徑并且自動(dòng)創(chuàng)建不存在的目錄。另外如果目標(biāo)文件已經(jīng)存在是覆蓋還是跳過我的默認(rèn)行為是覆蓋前詢問除非用戶加了--force參數(shù)。這個(gè)設(shè)計(jì)避免了誤覆蓋重要文件。權(quán)限問題在Linux和macOS上比較常見如果輸出目錄沒有寫權(quán)限會(huì)直接報(bào)錯(cuò)。這時(shí)候錯(cuò)誤提示要明確告訴用戶是哪個(gè)目錄沒有權(quán)限而不是拋一個(gè)底層的PermissionError。5.3 片段檢索的性能優(yōu)化經(jīng)驗(yàn)當(dāng)片段數(shù)量超過幾百個(gè)的時(shí)候簡單的遍歷檢索就會(huì)變慢。我的優(yōu)化經(jīng)驗(yàn)是建立多級(jí)索引第一級(jí)按標(biāo)簽索引第二級(jí)按語言索引第三級(jí)按關(guān)鍵詞索引。檢索的時(shí)候先走索引縮小范圍再在縮小后的集合里做模糊匹配。另外索引的持久化也很重要。如果每次啟動(dòng)都要重新構(gòu)建索引片段多了之后啟動(dòng)會(huì)很慢。我的做法是把索引也存成一個(gè)JSON文件啟動(dòng)時(shí)直接加載寫入時(shí)同步更新。這樣啟動(dòng)時(shí)間基本是常數(shù)級(jí)的。問題現(xiàn)象可能原因排查方法解決方案模板變量未替換變量名拼寫錯(cuò)誤檢查警告信息核對(duì)變量名輸出文件亂碼編碼不一致用file命令查看編碼統(tǒng)一UTF-8批量處理部分失敗路徑權(quán)限問題查看錯(cuò)誤日志檢查目錄權(quán)限檢索結(jié)果不全索引未更新檢查索引文件時(shí)間重建索引啟動(dòng)速度慢索引未持久化查看啟動(dòng)日志啟用索引緩存5.4 跨平臺(tái)兼容性的幾個(gè)關(guān)鍵點(diǎn)t3code如果要在Windows、macOS、Linux上都能跑有幾個(gè)地方要特別注意。路徑分隔符是最基本的用os.path.join而不是硬編碼/或\。換行符也要注意Windows是\r\nUnix是\n讀寫文件的時(shí)候用文本模式讓Python自動(dòng)處理。命令行參數(shù)的解析在不同平臺(tái)上基本一致但要注意Windows的PowerShell對(duì)某些字符的處理和bash不同。我踩過的一個(gè)坑是在Windows上用戶目錄是C:\Users\xxx包含反斜杠如果直接拼接到JSON字符串里會(huì)導(dǎo)致JSON解析失敗。解決辦法是用JSON庫來序列化而不是手動(dòng)拼接字符串。這個(gè)坑看起來低級(jí)但實(shí)際項(xiàng)目中真的很容易犯。6. 工具選型與擴(kuò)展思路6.1 什么時(shí)候該自己寫什么時(shí)候該用現(xiàn)成的做t3code這類工具之前先問自己一個(gè)問題現(xiàn)有的工具能不能滿足需求如果只是簡單的代碼片段管理VS Code自帶的Snippet功能就夠用了如果需要模板生成Yeoman、Cookiecutter這些成熟工具功能更全。自己寫的價(jià)值在于定制化和輕量化——現(xiàn)成工具往往功能太多、配置復(fù)雜而自己寫的工具可以完全貼合自己的工作流。我的判斷標(biāo)準(zhǔn)是如果現(xiàn)成工具能滿足80%的需求且剩下的20%可以通過簡單配置解決那就用現(xiàn)成的如果現(xiàn)成工具的使用成本比自寫還高那就自己寫。自寫工具的成本主要在維護(hù)所以功能要克制不要什么都想做。6.2 后續(xù)可以擴(kuò)展的方向t3code這類工具做出來之后有幾個(gè)自然的擴(kuò)展方向。第一是團(tuán)隊(duì)共享把片段庫放到共享目錄或者簡單的服務(wù)端團(tuán)隊(duì)成員都能訪問。第二是智能推薦根據(jù)當(dāng)前編輯的文件類型和內(nèi)容推薦相關(guān)的代碼片段。第三是版本管理片段的修改歷史記錄下來支持回滾。不過我要提醒一句擴(kuò)展要跟著需求走不要為了擴(kuò)展而擴(kuò)展。我見過太多工具第一版很好用第二版加了一堆功能結(jié)果變得臃腫難用。保持核心功能的簡潔比堆砌功能更重要。6.3 我個(gè)人的使用體會(huì)最后分享幾個(gè)我在實(shí)際使用這類工具時(shí)的心得。第一模板要少而精。我一開始建了二十多個(gè)模板結(jié)果常用的就三四個(gè)其他的都忘了。后來精簡到五個(gè)每個(gè)都反復(fù)打磨使用效率反而更高。第二片段要定期清理。有些片段存進(jìn)去就再也沒用過定期清理能保持片段庫的可用性。第三命令要短。t3code gen比t3code generate少敲幾個(gè)字符日積月累能省不少時(shí)間。還有一個(gè)小技巧把常用的命令做成alias或者腳本。比如我經(jīng)常用t3code gen api.tpl -o ./api.py -v nameuser就把它寫成一個(gè)shell函數(shù)下次只需要敲一個(gè)短命令就行。工具是死的用法是活的怎么順手怎么來。