Item 47: Consider Rewriting the Suspect Code in Another Language#

當你嘗試修復的程式碼就是不配合時，一個極端的手段是用另一種語言重寫有問題的程式碼。選擇更好的程式設計環境，你希望能完全繞過 bug，或透過更好的工具來發現和修復它。

選擇更具表達力的語言#

目標語言應該比目前的語言更具表達力：

• 複雜的交易策略可以用具有 functional programming 支援的語言（如 R、F#、Haskell、Scala、ML）更容易表達
• 透過語言的函式庫也能獲得表達力（如 R 用於統計計算）
• 複雜的字串處理和動態集合操作，可以考慮從 C 改用 C++ 或 Python

更具表達力的語言會產生更精簡的實作，減少出錯的機會。

其他考量#

• 容易觀察行為：scripting languages 透過 REPL (read-eval-print loop) 提供漸進式建構和測試的優勢
• Unix tool pipelines：可以逐步建構處理管線，逐階段驗證輸出
• 更好的開發工具：如果原始開發系統缺乏良好的 debugging、logging 或 unit testing framework，換到改進的環境可以利用其工具來定位問題

獲得可運作的新程式碼後#

有兩個選擇：

採用新程式碼：

• 當兩種語言之間有良好的 bindings 時可以這樣做（例如從 C 呼叫 C++）
• 也可以將新實作作為獨立的 process 或 microservice 來運行

用新程式碼作為 Oracle：

• 觀察運作程式碼和失敗程式碼之間的行為差異
• 比較兩個實作的變數和函式回傳值
• 逐步讓兩個 code base 收斂，直到 bug 浮現（見 Item 45）

重點回顧#

• 用更具表達力的語言重寫無法修復的程式碼，減少潛在錯誤語句的數量
• 將有 bug 的程式碼移植到更好的程式設計環境，以增強除錯武器
• 一旦有了替代的可運作實作，可以直接採用，或用它作為 oracle 來修復原始版本