作為程式開發者,每次聽到「加個 flag 就好」或者「開個變數存起來」這種話總是會心頭一驚。理由也很正常,就是像這樣子的 workaround 並沒有真正解決問題,只是徒留技術債,以後怎麼爆炸的都不知道。
workaround 聽起來真的是十惡不赦,不是嗎?
可凡存在必有道理,不如來聊聊 workaround 的好處在哪(?)
先來看看哪些情況下我們會以 workaround 作為解法
當然也有可能只是單純因為偷懶 — 不過這也代表開發者狀態不好或者對工作品質要求過低。重要的可能不是 workaround 本身,而是產生這個 workaround 的背後原因到底是什麼。
或者,換句話說,一個好的 workaround 應該要能夠展現其不得已以及當下的妥協。
既然 workaround 可能是來自某些當下的不得已,那與其檢討其結果不如討論如何好好的控制其範圍。
把視角拉遠看,長期開發的目的是追求可持續性,會有以下兩個目標
結合這兩點思考就會發現其實 workaround 可能不過是某種開發方式。
畢竟有時候站在系統及營運層次來看,在某些時候快速反應、減少重工,甚至是暫時封住問題可能會比徹底消除隱患來的重要。
workaround 可能在開發上有消極意義,但站在管理及大系統層面來看可能具有某種積極意義 — 只要我們能將其生命週期好好的嵌入進迭代中。
我們可能可以這樣做,假如判斷當前狀態需要下 workaround 時,除了 coding 本身之外,再多做幾件額外的事情
也就是說,倘若我們將 workaround 視為是解決問題的階段一,目的是引出後面根除的流程,那其實問題就不會太大。
真實世界的開發是多個維度妥協下的產物,限制可能來自於客戶需求、團隊能力、框架成熟度及資源配置,工具箱多點招數及彈性不會是壞事。
但這並非代表 workaround 就可以被接受,頭痛醫頭腳痛醫腳始終不是正道。只能說在兼顧長期可控及短期可用的原則下,workaround 並沒有這麼十惡不赦。
普拿疼畢竟不是萬靈丹,對吧!
忻旅科技:https://www.revtel.tech/
Sam Huang:https://www.sam-huang.info/