Workaround 一定是十惡不赦的嗎?
作為程式開發者,每次聽到「加個 flag 就好」或者「開個變數存起來」這種話總是會心頭一驚。理由也很正常,就是像這樣子的 workaround 並沒有真正解決問題,只是徒留技術債,以後怎麼爆炸的都不知道。
workaround 聽起來真的是十惡不赦,不是嗎?
可凡存在必有道理,不如來聊聊 workaround 的好處在哪(?)
![](https://imagedelivery.net/kDRCweMmqLnTPNlbum-pYA/prod/embed/1b790fc9-90ae-49e8-8e17-2647ac192c1d.png/public)
Workaround — 權衡下的妥協
先來看看哪些情況下我們會以 workaround 作為解法
突發事件下的緊急修復:當系統發生意外(比如重大錯誤或者漏洞),此時為避免事態擴大,緊急下 workaround 來修復是個不錯的做法。
第三方套件造成的問題:引入第三方套件的目的就是要「使用」而非「重製」,在這種情況下遇到問題或者不符使用時下些 workaround 繞開或補丁可能就是個常見做法。
歷史代碼的封裝:陳年舊程式碼往往無法保證其正確性,復用時透過 workaround 隱藏錯誤可能是必要的。
不確定的環境及平台問題:程式的正確不只是內在邏輯正確即可,還需要執行環境的配合,尤其在跨平台時這個狀況更容易發生,透過 workaround 可以將一些不值得深究的問題包裝起來。
…
當然也有可能只是單純因為偷懶 — 不過這也代表開發者狀態不好或者對工作品質要求過低。重要的可能不是 workaround 本身,而是產生這個 workaround 的背後原因到底是什麼。
或者,換句話說,一個好的 workaround 應該要能夠展現其不得已以及當下的妥協。
有好有壞,端看從哪個角度觀察
既然 workaround 可能是來自某些當下的不得已,那與其檢討其結果不如討論如何好好的控制其範圍。
把視角拉遠看,長期開發的目的是追求可持續性,會有以下兩個目標
讓我們可以在需要時改動任何想改動的地方
讓軟體可以因應時間及環境變化帶來的任何改變
結合這兩點思考就會發現其實 workaround 可能不過是某種開發方式。
畢竟有時候站在系統及營運層次來看,在某些時候快速反應、減少重工,甚至是暫時封住問題可能會比徹底消除隱患來的重要。
workaround 可能在開發上有消極意義,但站在管理及大系統層面來看可能具有某種積極意義 — 只要我們能將其生命週期好好的嵌入進迭代中。
開發是連續過程 — 重點是對於邊界的掌控
我們可能可以這樣做,假如判斷當前狀態需要下 workaround 時,除了 coding 本身之外,再多做幾件額外的事情
記錄當前觀測到的問題:目的是確定此次治標的範圍,最好是連復現的辦法及相依性也留存
設想可能的問題成因及解法:目的提供未來治本時的建議參考
將徹底解決問題加入開發時程:一方面強調長期來看需要治本,一方面也是思考這次 workaround 的生命週期
也就是說,倘若我們將 workaround 視為是解決問題的階段一,目的是引出後面根除的流程,那其實問題就不會太大。
![](https://imagedelivery.net/kDRCweMmqLnTPNlbum-pYA/prod/embed/d97292eb-792b-410f-9f28-e9e787cb1b6d.webp/public)
軟體工程 — 兼顧長期可控及短期可用
真實世界的開發是多個維度妥協下的產物,限制可能來自於客戶需求、團隊能力、框架成熟度及資源配置,工具箱多點招數及彈性不會是壞事。
但這並非代表 workaround 就可以被接受,頭痛醫頭腳痛醫腳始終不是正道。只能說在兼顧長期可控及短期可用的原則下,workaround 並沒有這麼十惡不赦。
普拿疼畢竟不是萬靈丹,對吧!
喜欢我的作品吗?别忘了给予支持与赞赏,让我知道在创作的路上有你陪伴,一起延续这份热忱!