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

[yauhh (喲)]

※ 引述《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)
推 ssadow:你這問題跟原PO的不一樣 原PO碰到的是邏輯完全一樣
→ ssadow:但是由不同thread執行 而你舉的例子是兩個邏輯很像
→ ssadow:但其實是不同的 另外 你引用的推文不是原PO啊XDD
推 tyc5116:對阿…我才是原原po…XD
推 typepeter:怎麼我被認為是原原PO了...XD 我推文在說共同邏輯
→ typepeter:而且最重要的是物件本身的責任歸屬 如果不同,不能簡單抽
→ typepeter:你說的情況是特例 但大部份時候若能避免就避免
→ typepeter:你的情況是抽的人沒有用心改,只是為抽而抽 這才是重點
→ typepeter:不能只因為有人不會抽,就說工作時不要避免重複程式碼
→ typepeter:難道因為槍會膛炸,所以改回冷兵器時代嗎...
→ typepeter:突然發現原PO第一段和最後一段有點嘲諷的意味XD 何必呢
→ typepeter:什麼狂不狂妄並不重要 重點在於要修改就要測試 如此爾爾
→ typepeter:如果作了改動,卻沒有相對測試去驗證 那是個人問題
→ typepeter:去改動的前提也在於你理解改動程式作什麼,並有測試驗證
→ typepeter:即便Scenario不一樣,也可以透過抽象化來實作不同處理
→ typepeter:並不是不能抽,而是要有把握及對應測試再去抽 這才是重點
→ TonyQ:這種情況其實不是特例啊，判斷是否重複本來就不是從程式碼
→ TonyQ:判斷，而是從意圖判斷。
→ TonyQ:只能從抽象化處理是另一件事，問題是如果你只用「一樣的程式
→ TonyQ:碼」，就覺得所有這些程式碼未來都該接受一樣的改動。
→ TonyQ:那就得想想了。
→ TonyQ:重點還是在於瞭解你要改的東西。
→ TonyQ:沒事不要把特例掛嘴上，不然每件事都是特例了。
→ TonyQ:一般來講比較安全的部份主要是抽 util 跟 base class。
→ TonyQ:最一開始案例比較像是抽 base class，應該比較難碰到這問題
→ TonyQ:但提醒一下不要只為了抽而抽，當然也不是壞事囉。
→ TonyQ:反正作任何改動提高警覺就是了，也不用因噎廢食到不改就是了
→ typepeter:但若把這個意圖不同的作法和意圖相同作法合為一談,那..?
→ typepeter:或許特例的用語不精確吧,但想表達的意思是:情境不同
→ typepeter:當然不止抽象化一個作法 因為涉及責任歸屬問題
→ typepeter:如TonyQ大所說,若非該Class之責,傾向抽util,反之則base
→ typepeter:不如說,是改動的風險是否自己可以承受的問題
→ typepeter:或許原PO想表達的是這一點 而不是重構本身可不可作
→ typepeter:另,原PO似乎常引起筆戰 還是少嘲諷口氣比較好
→ typepeter:像"小朋友" "狂妄" "輕忽地嗤笑" "歉意" "覺得自己對"
→ typepeter:"何必來討論" 這些情緒字眼可以減少 別人看了會較舒服
→ typepeter:總不能因為別人質疑你的看法 就出現這樣的字句
→ TonyQ:是還好啦，最一開始的確只提到是同一群模組跟程式碼一樣
→ TonyQ:至於語氣，我覺得討論就大家多擔待點吧。本來每個人撰文用詞
→ TonyQ:風格有別，只要沒有到謾罵的程度基本上就先將就著看吧。
→ TonyQ:至少 yauhh 提供一個實務 case 增加討論的豐富程度了。
→ TonyQ:也總不是壞事XD
→ tyc5116:請問上面提到的util是…?
→ remmurds:寫軟體也開始搞學長學弟制了嗎?要不要來塊國防布?
→ TonyQ:@tyc5116 是程式架構裡面的一種類型
→ TonyQ:reference http://en.wikipedia.org/wiki/Utility_class