Re: [心得]以策略模式重構switch case或if (影片)
※ 引述《landlord (91)》之銘言:
: 最近在客戶那邊一起 pair 重構 legacy code,
: 碰到了一大段 if/else statement,用來判斷什麼時候該使用哪一種cache,
: 並依照不同 cache 的邏輯來決定回傳的內容。
: 發現還是有蠻多風氣比較封閉的公司對這類型的基本功跟處理不是很熟悉,
: 可能是對 code smell 不熟,對重構不熟,對 design pattern 不熟,對工具不熟。
: 因此,我用自己幾年前的一個「計算運費」的範例,設計成這類型程式碼重構的簡介。: 這個範例之前是 C#,這次示範我改用 Java,用 IntelliJ 來重構。
: 有整個重構過程的 IDE 操作影片,也有每一個重構 baby steps 的 commit history。: 影片:https://youtu.be/zO-NnNC-xyg
: GitHub commit history: https://bit.ly/strategy-91
: 也可以參考 《Refactoring to Patterns》 的
: Replace Conditional Logic with Strategy:
: https://www.informit.com/articles/article.aspx?p=1398607&seqNum=2
: IntelliJ/Android Studio 在重構上還是地表上最強的兵器啊。
上回用 Java + IntelliJ 來重構一堆 if/else 的計算運費範例,
這次改用 C# + Rider 來重構一樣的例子,方便習慣 C# 的朋友參考與練習,
不過這次刻意改用 Func<T> 來當作 strategy 的實作內容,
以 function 來取代,省去 class + interface 的部份。
兩種作法適用場景不同,東西夠小夠單純,想要少一點 class/interface 等 elements,可以先這樣做,到真的有需要時,對熟悉重構的人來說,
要從 Func<T> 重構成 class + interface 只是一塊小蛋糕而已。
## Reference
1) C# + Rider Youtube 版影片:https://youtu.be/9rfVe6Uikt0
2) GitHub commit history: http://bit.ly/strategy-csharp
註:一般人的 Rider 沒有那個「把三元判斷式 自動替換成 Math.Min()」的燈泡,
那是我自己刻到 IDE 裡面的。
--
推91 你真的很猛
c#的有repo嗎?
我眼殘,看到了
運費在cart裡面算,是因為你的範例不想要太多class?
上個java版本,我有用interface+class用多型取代switch
這次則是刻意只用到function來做,需要class再抽就好
兩種給大家比較一下囉
好文推
1
原原 PO 用 interface 的好處是,shipper 有新的行為時。 可以很簡單的在 interface 加新的 function。 同時可以檢查有 implement Shipper 的 class 要加入新的 function。 感覺上,彈性更好。 缺點嘛... 如果 shipper 很多時每個都要再補 function 是比較累一點。12
終於有空來加入討論啦~ 這邊有 markdown 好讀版: 這邊我也來提一下我的看法。為了閱讀方便我把一些 code snippet 複製在這邊: ```java= public double shippingFee(String shipper, double length, double width, double3
因為有朋友想要 Python 的版本, 簡單的 legacy code 也可以讓他們玩玩 team build 練練手, 所以我就順手整理了 Python 的版本了。 - GitHub Repo & commit history: - 用 PyCharm 重構的影片,YouTube:6
恕刪 策略模式不就是一個戰鬥機器人 防禦模式就護甲值+20 攻擊模式就攻擊力+50 閃避率-10% 回復模式就自動補血+5hp18
首Po最近在客戶那邊一起 pair 重構 legacy code, 碰到了一大段 if/else statement,用來判斷什麼時候該使用哪一種cache, 並依照不同 cache 的邏輯來決定回傳的內容。 發現還是有蠻多風氣比較封閉的公司對這類型的基本功跟處理不是很熟悉, 可能是對 code smell 不熟,對重構不熟,對 design pattern 不熟,對工具不熟。
35
[討論] 重構跟kpi的考量假設以下情境 有個功能A、B都會用到相同邏輯,且有兩份重覆的code (沒有unit test保護,而且年久失修 要加入unit test會需要更多時程) 現在要加入C,也會用到相同邏輯 身為合格的工程師 應該會把ABC重覆的部份提取出來16
Re: [請益] 這種情況要怎麼重構1. 你不應該去動別人開發中的 code, 除非 pair 或你是有被授權的人. 2. 你可以使用他的 code , 建 common, 但你不應該改回他的部分(理由1). 3. 假設改完會有衝突, 那表示你做的不是重構. 4. 如果完成再重構會花更多時間, 那表示你做的不是重構. 5. 你要用他的 code , 跟你要整理重構, 是兩回事.15
Re: [請益] 這種情況要怎麼重構我這篇寫的跟原原PO的狀況無關 ※ 引述《tbpfs ( )》之銘言: : 其實我真的不懂為什麼要急著重構 : 有好處嗎? : 一般而言,重構都是發生在農閒的時候2
Re: [請益] 這種情況要怎麼重構如果專案有deadline的壓力建議是先各自發展以不相互影響為前提,最後再用剩餘時間開 一個分支做重構。其實這就是在規劃專案時沒有一個主要主導的設計人,沒有定義從系統 到功能的分工,導致代碼重工,而且缺乏溝通。 真的建議未來有機會在主導你還是要自己學會定義好工作,先學習不寫code就可以訂出功 能以及架構。我自己工作後常常遇到工程師很喜歡自幹,還沒開始就急著寫code,而不是2
Re: [討論] 重構之前要寫測試 不然不要重構人生在世,吃飯跟拉屎都是要做的,應該沒有人會說, 要先吃飯不然別拉屎,還是先拉屎不然別吃飯。 改扣就是改扣,框個名字自稱叫重構, 是不是不知道,但即使是重構,本質還是改扣。 測試是為了改扣順利,不寫測試還是可以改扣。2
Re: [請益] coding style差太多怎辦?重構取決於你對自己的程度有多自信 假設已經發現問題 也覺得自己有能力修改 試著跟主管溝通看看 說「在自己任務時程不耽誤的前提下 有路過看到程式碼就稍微整理一下」 若有得到主管或同事許可就下去改 沒把握自己可以改好的話 量力而為 先從小區塊開始改起