關於解耦的一些想法
前兩天，臉書的工程師抱怨社團出現一篇抱怨文，讓羅賓想把自己的一些想法記錄一下。
這篇抱怨文的內容大概是 :
工程師 ( 猜測應該是用Unity寫遊戲程式 ) 要做一段功能 – 播放劇情 -> 等玩家操作介面 -> 關閉介面 -> 播放下一段劇情。
而這位工程師原本的想法是使用await來等待每個步驟的完成，卻被他口中的解耦魔人要求採用事件驅動的方式，每個步驟的完成，改成發送事件，讓事件來觸發下一個步驟。
這麼做的理由當然是解耦。
抱怨的細節就不說了，沒什麼紀錄的必要。只是，這位工程師的想法思路，跟羅賓曾經的同事非常像，讓人一度懷疑就是他本人，而那個解耦魔人就是羅賓本人。 😂
解耦與否，應該在於是否需要解耦，工程師在抱怨文的最後，也是提出這樣的看法。所以先說說這點。
這段功能，至少牽涉兩個模組，一個是劇情播放，一個是遊戲介面，這兩個模組不僅被功能耦合(使用到了模組的功能)，甚至也被行為耦合(使用await來等待)。而這兩個模組，算是遊戲的核心內容，也就是變動的機會非常高，一旦進行變動，難保不會牽涉到工程師所做功能。而且，因為是在功能以及行為上的耦合，變動後的測試就必須做得更多更詳盡。
變動性高、功能與行為耦合、核心內容的模組，還是把耦合度降低下來好。
這不單純是著眼於現在，更是著眼於未來。
羅賓曾經的同事會說，「你這是在預測未來的變化?」
「不不不，不是預測未來的變化，是預測未來會變化。」
差一個字差很多。
這三個模組 ( 我們把工程師要做的功能也視作一個模組好了 ) ，在可長可短的未來中，非常高的機率會變動，我們解耦之後，可以增加適應變化的彈性，也因為我們不知道未來會發生什麼變化，所以我們只保留了彈性。
– 如果我們知道未來的變化，那就直接實作在裡面，也不需要做多餘的解耦啦!! –
也許羅賓認為的這三個模組根本沒有區分模組，那真的還不到需要解耦的程度，他們需要的，是把模組架構好好的分清楚，一團大泥球是不需要解耦的。
說實話，如果羅賓也被稱作是解耦魔人，那也挺值得驕傲的~~~
Comments