Re: [討論] 一段想重構的程式碼

看板Soft_Job作者 (喲)時間11年前 (2013/07/27 22:12), 編輯推噓3(3推 0噓 43→)
留言46則, 5人參與, 最新討論串9/10 (看更多)
※ 引述《yauhh (喲)》之銘言： : 推 typepeter:如果只是二個,就沒差 問題是重複的Bug,就很慘 07/25 23:56 : → yauhh:怎麼會沒差呢? 你可要在50~60個classes中,認得有2個共用func 07/26 00:00 : → typepeter:完全一樣的動作建議還是抽出,copy/paste除錯會更慘 07/26 00:00 : → yauhh:光是要花費在記憶這種特例的精神,就讓人怨恨死你了. 07/26 00:01 : → typepeter:今天若是二個function,不抽共同邏輯沒關係 多個,很慘 07/26 00:01 : → typepeter:如果paste全部都是copy/paste的動作,將有大量時間浪費 07/26 00:02 : → yauhh:除非你具有獨立性質的邏輯抽出來做個單元,是有用的. 07/26 00:02 : → typepeter:所以我提到的是: 是可以獨立的邏輯,抽出共同邏輯 07/26 00:03 : → yauhh:或者趁幾次修改時,將新加的碼放在獨立的單元中. 07/26 00:04 : → typepeter:不然一樣的邏輯問題 又要去改數個拷貝貼上的重複 很慘 07/26 00:04 : → yauhh:但是,應該要搞清楚這是在工作. 重構是為了工作,還是為了高興 07/26 00:05 : → typepeter:工作效率其實可以從減少浪費時間作起 07/26 00:05 : → typepeter:如果一樣是作事情,建議可以減少機械動作 07/26 00:06 : → yauhh:那你最好算一算,到底減少浪費了多久時間. 07/26 00:06 : → typepeter:如果你漏了改某個地方呢? 那之後還要debug 07/26 00:07 : → typepeter:這是bad smell之中最為人知的其中一個: duplicated code 07/26 00:07 : → typepeter:算上機械動作,加上檢查是否漏改,以及漏改的debug時間 07/26 00:11 : → typepeter:應該減少duplicated code會比較節省時間 07/26 00:11 : → typepeter:此外,若沒有抽共同邏輯 同一個邏輯將會發展無數版本 07/26 00:16 : → typepeter:之後光是閱讀及維護 可能要找出原本的同樣debug,就累死 07/26 00:16 你寫得這樣落落長,我的感覺是,前文中你說 "想說尊重一下主管好了" 其實根本沒有尊重,其實你就是覺得,雖然你的想法還沒實現,但就是覺得你自己對嘛. 所以別人的建議,你根本沒看. 那又何必來此貼文或推文討論呢? 我最近就遭遇一個情況,跟你這事情一樣, class a 和 class b 有一段程式完全相同. 但是,經過一番折騰,後來更明確知道的是,二個 class 執行的環境不一樣. 一個程式執行在網站上,而另一個程式執行在Windows排程中. 因為相信二個程式相同,所以前人在修改 class a 的 func 時, 同時也修改 class b 的 func. 而因為相信二個程式是一樣的,所以修改方式就是從 class a func 整段複製 然後轉貼到 class b func, 而且沒有測試 class b. 最近,我發現 class b 存在問題,是因為 class a func 中加了XSS檢查,而XSS檢查是 有去取網站的設定參數. 這就造成 class b 的問題了. class b 執行環境中並沒有 網站設定參數可查,而程式的寫法是當XSS檢查無效時,傳回的資料是空值. value = xssCheck(value); 在這種情況,該死的就是 *相信二段程式邏輯相同* 所以就直接貼而不做個別驗證. 雖然這個情況不是像你所做的,把二個 func 抽出來做成同一個,但是,我就做了跟你 所講的一模一樣的事情,我把二個 func 共同的一段邏輯拿出來放到 class c 的 func. 但重點就是 class a 和 class b 執行環境不同,所以這樣做是很難維護的. 而且這給我造成的麻煩是,後來知道 class b 是獨立的執行環境,本來我只是做了 改改程式的動作,但是後來卻要思考如何部署的問題. 同理,你硬要把 class a 和 class b 拉出共同的 func, 說這樣子很好 debug, 那就祝你好運. 但是,最重要的是要勸你,要正視工作,工作是有責任的; 你今天這樣 做下去,假如將來減少了維護的效益,你應該要有相同的行動力承擔錯誤並且為事情 負責. 否則,像你現在這樣輕忽地嗤笑著 legacy code, 其實很多小朋友都如此狂妄, 但是,卻對於程式結構突然大調整,影響到同事及主管的認知,不帶著一點歉意, 這說不過去. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 36.226.96.67 ※ 編輯: yauhh 來自: 36.226.96.67 (07/27 22:18)
推
07/27 22:43, , 1F
你這問題跟原PO的不一樣 原PO碰到的是邏輯完全一樣
07/27 22:43, 1F
→
07/27 22:43, , 2F
但是由不同thread執行 而你舉的例子是兩個邏輯很像
07/27 22:43, 2F
→
07/27 22:43, , 3F
但其實是不同的 另外 你引用的推文不是原PO啊XDD
07/27 22:43, 3F
推
07/27 22:47, , 4F
對阿…我才是原原po…XD
07/27 22:47, 4F
推
07/27 23:21, , 5F
怎麼我被認為是原原PO了...XD 我推文在說共同邏輯
07/27 23:21, 5F
→
07/27 23:22, , 6F
而且最重要的是物件本身的責任歸屬 如果不同,不能簡單抽
07/27 23:22, 6F
→
07/27 23:23, , 7F
你說的情況是特例 但大部份時候若能避免就避免
07/27 23:23, 7F
→
07/27 23:24, , 8F
你的情況是抽的人沒有用心改,只是為抽而抽 這才是重點
07/27 23:24, 8F
→
07/27 23:24, , 9F
不能只因為有人不會抽,就說工作時不要避免重複程式碼
07/27 23:24, 9F
→
07/27 23:25, , 10F
難道因為槍會膛炸,所以改回冷兵器時代嗎...
07/27 23:25, 10F
→
07/27 23:30, , 11F
突然發現原PO第一段和最後一段有點嘲諷的意味XD 何必呢
07/27 23:30, 11F
→
07/27 23:31, , 12F
什麼狂不狂妄並不重要 重點在於要修改就要測試 如此爾爾
07/27 23:31, 12F
→
07/27 23:32, , 13F
如果作了改動,卻沒有相對測試去驗證 那是個人問題
07/27 23:32, 13F
→
07/27 23:37, , 14F
去改動的前提也在於你理解改動程式作什麼,並有測試驗證
07/27 23:37, 14F
→
07/27 23:38, , 15F
即便Scenario不一樣,也可以透過抽象化來實作不同處理
07/27 23:38, 15F
→
07/27 23:39, , 16F
並不是不能抽,而是要有把握及對應測試再去抽 這才是重點
07/27 23:39, 16F
→
07/28 00:53, , 17F
這種情況其實不是特例啊，判斷是否重複本來就不是從程式碼
07/28 00:53, 17F
→
07/28 00:53, , 18F
判斷，而是從意圖判斷。
07/28 00:53, 18F
→
07/28 00:54, , 19F
只能從抽象化處理是另一件事，問題是如果你只用「一樣的程式
07/28 00:54, 19F
→
07/28 00:54, , 20F
碼」，就覺得所有這些程式碼未來都該接受一樣的改動。
07/28 00:54, 20F
→
07/28 00:54, , 21F
那就得想想了。
07/28 00:54, 21F
→
07/28 00:54, , 22F
重點還是在於瞭解你要改的東西。
07/28 00:54, 22F
→
07/28 00:55, , 23F
沒事不要把特例掛嘴上，不然每件事都是特例了。
07/28 00:55, 23F
→
07/28 00:56, , 24F
一般來講比較安全的部份主要是抽 util 跟 base class。
07/28 00:56, 24F
→
07/28 00:57, , 25F
最一開始案例比較像是抽 base class，應該比較難碰到這問題
07/28 00:57, 25F
→
07/28 00:57, , 26F
但提醒一下不要只為了抽而抽，當然也不是壞事囉。
07/28 00:57, 26F
→
07/28 01:03, , 27F
反正作任何改動提高警覺就是了，也不用因噎廢食到不改就是了
07/28 01:03, 27F
→
07/28 01:10, , 28F
但若把這個意圖不同的作法和意圖相同作法合為一談,那..?
07/28 01:10, 28F
→
07/28 01:11, , 29F
或許特例的用語不精確吧,但想表達的意思是:情境不同
07/28 01:11, 29F
→
07/28 01:12, , 30F
當然不止抽象化一個作法 因為涉及責任歸屬問題
07/28 01:12, 30F
→
07/28 01:13, , 31F
如TonyQ大所說,若非該Class之責,傾向抽util,反之則base
07/28 01:13, 31F
→
07/28 01:14, , 32F
不如說,是改動的風險是否自己可以承受的問題
07/28 01:14, 32F
→
07/28 01:14, , 33F
或許原PO想表達的是這一點 而不是重構本身可不可作
07/28 01:14, 33F
→
07/28 01:31, , 34F
另,原PO似乎常引起筆戰 還是少嘲諷口氣比較好
07/28 01:31, 34F
→
07/28 01:32, , 35F
像"小朋友" "狂妄" "輕忽地嗤笑" "歉意" "覺得自己對"
07/28 01:32, 35F
→
07/28 01:33, , 36F
"何必來討論" 這些情緒字眼可以減少 別人看了會較舒服
07/28 01:33, 36F
→
07/28 01:35, , 37F
總不能因為別人質疑你的看法 就出現這樣的字句
07/28 01:35, 37F
→
07/28 01:39, , 38F
是還好啦，最一開始的確只提到是同一群模組跟程式碼一樣
07/28 01:39, 38F
→
07/28 01:41, , 39F
至於語氣，我覺得討論就大家多擔待點吧。本來每個人撰文用詞
07/28 01:41, 39F
→
07/28 01:42, , 40F
風格有別，只要沒有到謾罵的程度基本上就先將就著看吧。
07/28 01:42, 40F
→
07/28 01:43, , 41F
至少 yauhh 提供一個實務 case 增加討論的豐富程度了。
07/28 01:43, 41F
→
07/28 01:43, , 42F
也總不是壞事XD
07/28 01:43, 42F
→
07/28 06:53, , 43F
請問上面提到的util是…?
07/28 06:53, 43F
→
07/28 09:32, , 44F
寫軟體也開始搞學長學弟制了嗎?要不要來塊國防布?
07/28 09:32, 44F
→
07/28 12:42, , 45F
@tyc5116 是程式架構裡面的一種類型
07/28 12:42, 45F
→
07/28 12:42, , 46F
07/28 12:42, 46F
‣ 更多 yauhh 的文章
文章代碼(AID): #1HyzLgDC (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 9 之 10 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共10篇)
‣ 更多 yauhh 的文章
文章代碼(AID): #1HyzLgDC (Soft_Job)