刪掉1300行代碼后，我終于不累了

一個人維護兩套系統，聽起來是"雙保險"，實際是"雙倍痛苦"。這位獨立開發者用血淋淋的教訓證明：代碼能跑，不代表架構沒問題。

一圖讀懂：從"雙軌制"到"單核驅動"

整個故事可以用一張簡單的架構圖概括——

【改造前】TypeScript實現 ? 功能對齊 ? Python實現，兩套代碼并行迭代，每次改功能要改兩遍，修Bug要修兩遍，測試邊緣情況要測兩遍。

【改造后】Python核心（唯一真相源）→ Node封裝層（僅負責分發和啟動），刪掉1300行TypeScript業務代碼，邏輯全部收歸一處。

這張圖的精髓在于： distribution（分發）和 core（核心）必須分離，但只能有一個 core。

最初的陷阱：能跑就行

作者開發 ExplainThisRepo，一個幫開發者快速理解陌生代碼庫的命令行工具。它不靠AI瞎猜，而是用真實信號——入口文件、配置文件、依賴關系、清單文件——告訴你從哪開始看、什么重要、什么可以忽略。

項目需要同時服務Python和JavaScript生態，于是他很自然地做了兩件事：

第一，用Python寫了一套實現，能跑通。

第二，用TypeScript重寫了一遍，保持功能完全一致，也能跑通。

當時看起來沒毛病。甚至有點優雅：兩種語言的開發者都能拿到"原生"體驗，沒有跨語言調用的別扭感。

但作者很快發現，每次發新功能不是寫一次，是寫兩次。每次修Bug不是修一次，是修兩次。更隱蔽的麻煩是：他必須確保兩套實現在不同語言里行為一致，輸出一致，邊緣情況處理一致。

這不是封裝關系，是平行宇宙關系。兩個獨立系統，相同的功能、行為、輸出和邊緣情況，用不同語言各自實現一遍。

作者的原話很直白：「That slowed everything down and was very painful to maintain alone」。慢不是因為系統復雜，是因為所有事情要做兩遍。

關鍵判斷：不是選語言，是選"唯一真相源"

走到這一步，常見的錯誤思路是：TypeScript和Python哪個更好？要不要全面遷移到某一邊？

作者的決策框架更冷靜。他問自己：哪邊的實現應該成為 single source of truth（唯一真相源）？

這是一個架構問題，不是語言偏好問題。他的結論是：一個系統只能有一個真相源，其他都是分發層。

具體選擇Python，基于三個可觀察的事實：

第一，Python那邊的新功能上線更快，已經是事實上的主力開發分支。

第二，核心邏輯在Python側更穩定，迭代效率最高。

第三，如果強行把TypeScript扶正，要么整體遷移開發重心（成本高），要么繼續雙軌并行（痛苦持續）。

所以方案是：不動核心，砍掉重復。保留Python作為唯一實現，Node側退化為純啟動器和分發包裝。

技術細節：怎么讓用戶無感

改造后的架構很簡潔。Node端不再運行任何業務邏輯，只做三件事：打包進npm、接收命令行參數、啟動預編譯的Python二進制文件。

這個Python二進制是預構建的，用戶機器上不需要安裝Python環境。對終端用戶來說，命令還是那個命令，體驗沒有變化。但背后的復雜度從兩套代碼收斂到一套。

作者刪除了約1300行TypeScript代碼。這個數字值得玩味——它不是"優化"掉的冗余代碼，是整段整段的功能實現被物理刪除。這些代碼曾經能跑、有測試、維護過，但現在成了架構債務。

GitHub上的PR鏈接是公開的，有興趣可以翻翻看哪些模塊被連根拔起。

為什么"保持兩者"注定失敗

作者專門回應了一種想法：「我就同時維護兩套，小心點就行」。

他的判斷是：早期確實能work，但不可持續。核心原因在于"隱性成本"的指數增長。

顯性成本是開發時間翻倍，這很容易看見。隱性成本包括：兩套代碼的行為漂移（behavior drift）、測試用例的重復編寫、邊緣情況的覆蓋差異、文檔同步、新人 onboarding 的認知負擔。

當項目只有一個人維護時，這些成本被壓縮到同一個人身上，沒有緩沖。作者的原話是「painful to maintain alone」——alone這個詞很關鍵，團隊至少還能分工，一個人就是純純的體力消耗。

更諷刺的是，兩套實現的存在感會自我強化。因為兩邊都能跑，你會傾向于"先改一邊，另一邊稍后同步"，然后稍后變成永遠。最終形成技術債的復利效應。

給獨立開發者的啟示

這個案例的普適性在于：它暴露了一種常見的早期架構陷阱。

當你需要跨語言/跨平臺支持時，"各寫一套原生實現"是直覺上最干凈的選擇。但干凈的是接口，臟的是維護。真正的干凈架構，是核心單一、分發輕薄。

另一個反直覺的點是：刪除代碼比添加代碼更需要勇氣。1300行能跑的代碼，說刪就刪，需要對自己系統的邊界有清晰認知。很多人卡在"都寫了這么多了，棄掉可惜"的沉沒成本里。

作者的決策依據也很值得借鑒——不是看"哪邊代碼更多"，而是看"哪邊迭代更快、邏輯更穩"。這是一個動態判斷，基于開發流的實際狀態，而非靜態的代碼量對比。

最后，這個方案能成立，依賴于現代打包技術的成熟。預編譯二進制+跨平臺分發，讓"Python核心+Node外殼"的組合對用戶透明。如果沒有這層技術支撐，砍掉TypeScript實現可能會犧牲安裝體驗，決策就會更難。

所以這也提醒我們：架構選擇不是純理論推演，要同步考慮分發技術和用戶感知。

如果重來一次，你會在哪一步踩剎車？