Workaround 一定是十惡不赦的嗎？

作為程式開發者，每次聽到「加個 flag 就好」或者「開個變數存起來」這種話總是會心頭一驚。理由也很正常，就是像這樣子的 workaround 並沒有真正解決問題，只是徒留技術債，以後怎麼爆炸的都不知道。

workaround 聽起來真的是十惡不赦，不是嗎？

可凡存在必有道理，不如來聊聊 workaround 的好處在哪(？)

Workaround — 權衡下的妥協

先來看看哪些情況下我們會以 workaround 作為解法

1. 突發事件下的緊急修復：當系統發生意外（比如重大錯誤或者漏洞），此時為避免事態擴大，緊急下 workaround 來修復是個不錯的做法。

2. 第三方套件造成的問題：引入第三方套件的目的就是要「使用」而非「重製」，在這種情況下遇到問題或者不符使用時下些 workaround 繞開或補丁可能就是個常見做法。

3. 歷史代碼的封裝：陳年舊程式碼往往無法保證其正確性，復用時透過 workaround 隱藏錯誤可能是必要的。

4. 不確定的環境及平台問題：程式的正確不只是內在邏輯正確即可，還需要執行環境的配合，尤其在跨平台時這個狀況更容易發生，透過 workaround 可以將一些不值得深究的問題包裝起來。

5. …

當然也有可能只是單純因為偷懶 — 不過這也代表開發者狀態不好或者對工作品質要求過低。重要的可能不是 workaround 本身，而是產生這個 workaround 的背後原因到底是什麼。

或者，換句話說，一個好的 workaround 應該要能夠展現其不得已以及當下的妥協。

有好有壞，端看從哪個角度觀察

既然 workaround 可能是來自某些當下的不得已，那與其檢討其結果不如討論如何好好的控制其範圍。

把視角拉遠看，長期開發的目的是追求可持續性，會有以下兩個目標

• 讓我們可以在需要時改動任何想改動的地方

• 讓軟體可以因應時間及環境變化帶來的任何改變

結合這兩點思考就會發現其實 workaround 可能不過是某種開發方式。

畢竟有時候站在系統及營運層次來看，在某些時候快速反應、減少重工，甚至是暫時封住問題可能會比徹底消除隱患來的重要。

workaround 可能在開發上有消極意義，但站在管理及大系統層面來看可能具有某種積極意義 — 只要我們能將其生命週期好好的嵌入進迭代中。

開發是連續過程 — 重點是對於邊界的掌控

我們可能可以這樣做，假如判斷當前狀態需要下 workaround 時，除了 coding 本身之外，再多做幾件額外的事情

1. 記錄當前觀測到的問題：目的是確定此次治標的範圍，最好是連復現的辦法及相依性也留存

2. 設想可能的問題成因及解法：目的提供未來治本時的建議參考

3. 將徹底解決問題加入開發時程：一方面強調長期來看需要治本，一方面也是思考這次 workaround 的生命週期

也就是說，倘若我們將 workaround 視為是解決問題的階段一，目的是引出後面根除的流程，那其實問題就不會太大。

軟體工程 — 兼顧長期可控及短期可用

真實世界的開發是多個維度妥協下的產物，限制可能來自於客戶需求、團隊能力、框架成熟度及資源配置，工具箱多點招數及彈性不會是壞事。

但這並非代表 workaround 就可以被接受，頭痛醫頭腳痛醫腳始終不是正道。只能說在兼顧長期可控及短期可用的原則下，workaround 並沒有這麼十惡不赦。

普拿疼畢竟不是萬靈丹，對吧！