Workaround 一定是十惡不赦的嗎?

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

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

workaround 聽起來真的是十惡不赦,不是嗎?

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

Workaround — 權衡下的妥協

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

普拿疼畢竟不是萬靈丹,對吧!

CC BY-NC-ND 4.0 授权

喜欢我的作品吗?别忘了给予支持与赞赏,让我知道在创作的路上有你陪伴,一起延续这份热忱!

Sam Huang[ https://www.sam-huang.info/ ] 一扁帽,一壺酒,一溪雲,佔得人間一味愚,此心安處是吾鄉
  • 来自作者
  • 相关推荐

平淡但輕鬆的年假

工作所思所想

陽台種植物