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

[tyc5116 (累人啊....)]

如題,因為不知道適合PO在哪個板問,看來看去好像這裡比較適合的樣子

如果不妥我再轉板

我在接手別人的程式後,發現他架構有需要重構的地方

程式分了數個小模組(a和b都是一個模組)

class a{
   void func();
   ...
};

class b{
  void func();
  ...
;

...

其中每個模組的func程式碼都是一樣的

所以我想說就再拉出一個介面,並實作這個func,a和b都繼承這個介面

這樣這段重覆的程式碼就可以省掉了

因為改成這樣的方式變動有點大,所以尊重一下主管,跟主管說一聲,看能不能這樣改

但是主管卻說,程式內有很多個thread,若以這樣的方式來寫,可能在同一時間

會有很多地方都會執行到func,造成debug的不易,不然就還要再類別內加個屬性,

用來辨別目前執行func的是哪一個模組,雖然說目前是將同樣的func

寫在各別的模組內,但是這樣在debug時會比較容易作區分,然後他不贊成我改@@

我對這個理由其實不太認同的,我是覺得加個屬性作為區分即可

然後程式都會跑到相同的地方,debug應該會變的更容易才對阿!!

不知道大家的看法如何?

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 59.126.76.122
※ 編輯: tyc5116         來自: 59.126.76.122        (07/24 14:56)
→ azureblaze:看this就夠了連屬性都不用吧?
推 damody:branch 出來試吧？ 感覺一天就可以改完了。
→ realmeat:大概幾小時內的事情吧..
→ realmeat:確定流程, 程式搬一搬應該就結束了
→ StupidGaGa:程式的維護性與簡便性相衝突
→ StupidGaGa:我覺得除非有特殊需求，否則請以"容易維護"為最高標準
→ StupidGaGa:你要了解，也許你走了，接手你工作的人是否容易上手？
→ StupidGaGa:今天你看懂前任的程式，但下任是否看得懂你的程式？
推 dyco:同意樓上
→ hichcock:不同意GaGa, 因為"容易維護"沒有標準
→ hichcock:你永遠不知道之後接手的是神一樣的高手, 還是....
→ hichcock:你可以試試看, 寫完多驗一驗看會不會遇到問題
→ hichcock:只要確認不影響結果, 改好了老板也不會有意見
推 richardhesid:為什么會難以區分，CallStack不是可以看出來嗎？
→ hichcock:寫程式不要怕出錯, 怕出錯建議左轉去考鐵飯碗
→ azureblaze:copy&paste code絕對不是什麼容易維護的東西
→ azureblaze:哪天需要改他就頭大了
推 jackyu:程式的原作者可以問嗎?如果這是一個不算簡單的程式,那它的
→ jackyu:作者應該不會比你兩光多少, 你自己也說這樣改不算小改
→ jackyu:那就表示這樣寫是有它的原因的. 或許初期規劃沒有做的很好
→ jackyu:但是多線緒把callee統一拉出來絕對會有一鑼匡雞飛狗跳的問
→ jackyu:題,除非你全懂,要不然你永遠不知道哪邊藏個race condition
→ jackyu:的問題,小則crash,大則bug完全抓不出要怎樣改
→ tyc5116:我覺得這程式的規模不大,但對於社會新鮮人來說,算大
→ tyc5116:而因為若作這樣的修改,是"數個class"都要作修改
→ tyc5116:對於"公司"來說,這是個風險,所以我才沒有先幹再說的想法
→ tyc5116:但我也不覺得這樣的修改要花我多少時間,只是單純主管不贊
→ tyc5116:所以就提出來聽聽大家怎麼想
→ StupidGaGa:我對容易維護的定義很簡單 1. 直覺式的了解程式
→ StupidGaGa:2. 獨立性夠好
→ StupidGaGa:如果以原PO的方式，假設要做個別化的處理，就很麻煩
→ StupidGaGa:如果以原本程式，我只要針對那個class下去做處理
→ StupidGaGa:寫程式除非真的有特別的需求，不然請"容易維護"當基礎
→ StupidGaGa:你要有個自覺，老闆可能會要求你改功能
→ StupidGaGa:如果今天程式100年都不會變，老闆都不會要求你更改功能
→ StupidGaGa:我會採用你的做法，但是現實生活是，老闆常常要求改變
→ StupidGaGa:如果你程式獨立性不夠，牽一髮動全身，你會死得很慘
→ StupidGaGa:我語重心長的說，請不要把程式寫成BIOS的恐龍時代
→ StupidGaGa:連BIOS的恐龍都滅絕了，為什麼高階語言還要寫成那樣？
推 Lapha:贊同原Po的設計, Code Duplicate 是很多問題的根源
→ Lapha:至於主管的想法, 是典型的 "東西沒壞, 就別去動它"的思維
→ StupidGaGa:程式有句話：不要重複造輪子。我認同這句
→ StupidGaGa:重點是，你輪子的功用是要一模一樣的情況。
→ Lapha:關於Multi-Thread的問題, 如果一個thread就要寫一份code才安
→ Lapha:全, 那大家的Multi-thread code都要重新寫了.. XD
推 chatnoir:改啊為什麼不改\
推 richardhesid:GaGa,為什么個別化處理會麻煩。子類中redefine父類的
推 jackyu:Lapha, 多線緒的"design"和"refactor"是完全兩碼子事
→ richardhesid:的func()就可以了啊
→ jackyu:code dup是問題沒錯,當然原PO認為問題不大就branch出來改
→ jackyu:然後跑過所有regression都沒問題,那就算解了. 只要不要客戶
→ jackyu:說有問題然後追下去發現是refactor造成的,那絕對會算到你的
→ jackyu:考積裡
→ jackyu:小看成熟的產品自以為聰明的refactor讓程式"漂亮"然後害大
推 Lapha:我是要說明:原Po主管的理由,很難成立, 比起來,我寧願主管直
→ jackyu:家在deadline加班的情況看多了~_~
→ Lapha:接說:我們現在沒打算做Refactor,而不是用似是而非的理由搪塞
推 chatnoir:refactor如果只是看起來漂亮, 還叫refactor??
→ jackyu:重點是我們都沒看到這件事的全貌,包括主管的對話,整包src
→ Lapha:我知道小聰明的Refactor會害死人, 但這是現實上的考量, 不是
→ jackyu:話黑我講的漂亮你該不會是認為是行數少indent漂亮那種?
→ Lapha:程式設計上的考量
→ jackyu:我要講的很簡單,你問主管要不要改,表示要主管決定並擔責任
→ jackyu:你覺得憑估要改,那就改,爆掉自己擔, 就這樣
推 chatnoir:基本上沒把握重構比較好,那為何要重構? 跟行數有甚麼關??
→ jackyu:我認為要不要refactor是"業務需要"而非"工程師需要"
→ chatnoir:然後,我不是話黑,你或許可以再去查一下字典:(
→ jackyu:那貓黑你講的和我要講的應該是一樣的..
→ StupidGaGa:討論真熱烈～呵呵，原PO可以按照自己的經驗來寫
→ StupidGaGa:程式的經驗、架構、寫法會因為所處環境有所不同
→ StupidGaGa:不過原PO可以思考幾點
→ TonyQ:@StupidGaGa 很多複雜的 code 不是因為他不能寫得簡單，是因
→ StupidGaGa:1. Bug發生時，DEBUG的效率如何？
→ TonyQ:  為寫得簡單會出事，我還蠻常看到自以為改簡單，結果只是重
→ TonyQ:  踩前人中過的雷。xd
→ StupidGaGa:2. 後人維護與DEBUG是否容易？
→ TonyQ:我是覺得改就改，反正要改就做好測試。
→ TonyQ:所有影響到的地方都要稍微看一下，這是基本的禮貌跟尊重。
→ StupidGaGa:請用良心寫程式，程式寫出來容易，維護很靠杯
推 jackyu:TonyQ大和我的遭遇完全一模一樣...T_T
→ StupidGaGa:TonyQ,原PO是想把程式簡單化吧！？
→ StupidGaGa:基本上扯到Thread，我覺得主管的建議比較好
推 cashlalala:testing有做好想改就改阿
→ realmeat:主管太保守, 我就會改, 寫的太濫有的就整個砍掉重練
→ realmeat:不過還是看規模,影響範圍,跟現在有沒有空決定
→ TonyQ:@StupidGaga 有些修改是破壞性的，有些修改是非破壞性的，
→ TonyQ:  基本上重構應該做的是非破壞性的操作
→ TonyQ:但是就是會有笨蛋把看起來很像但其實不一樣的東西拿來「重構
→ TonyQ:」然後就爆了，或是以為可以少跑幾個迴圈之類的"優化"。
→ TonyQ:原 po 到底是怎麼樣我覺得不用多作臆測啦，但是有修改一定要
→ TonyQ:把所有會跑過那段 code 的地方前因後果看仔細，這是基本禮貌
→ TonyQ:千萬不要想當然爾的"看起來一樣"，所以就沒測，會死人的。
→ TonyQ:我不是「程式碼沒壞就別去動他」的信徒，我也會大改系統核心
→ TonyQ:，我信奉的是「要改就要認真讀原本的 code、要改就要測試」
推 bobju:要改可以,不過你在提案時要有足夠的誘因打動主管支持,不然就
→ bobju:是時機未到,多一事不如少一事
→ loveme00835:這個就解了 http://ppt.cc/vzjO
→ andymai:有先從商業邏輯來看嗎?如果沒有~很可能它的用法跟你想的不
→ andymai:一樣~如果是這樣~很可能它本來就該是個別處理...
推 gmoz:隨便亂改再加個 //Magic, DO NOT touch就好了
推 CGary:If it ain't broke, don't fix it
→ CGary:除非你還要針對這些程式做甚麼額外的事情 否則沒事找事改完
→ CGary:萬一將來出現bug, 甚麼事情都會直接扯上你今日動手修他的這
→ CGary:件事情 而且既然容易維護沒標準 只要不是非常髒的code 不用
→ CGary:特別拉他出來做一個 interface...
推 MacPerson:請教一下 為什麼不直接做繼承 還要先做個interface 做個
→ MacPerson:類別實作後，再原本的兩個類別繼承這個時做interdace的
→ MacPerson:類別，趁這個機會也讓我偷學一下  @@
→ MacPerson:在此也順便分享我的經驗，如果這個FUN是核心函式(重要)
→ MacPerson:除非他有BUG不然我不會動，除此之外 為了程式的可維護性
→ MacPerson:我會直接就下手囉~~
→ loveme00835:這邊應該是指 base class
→ StupidGaGa:繼承好用,但是在大部分的情況下，組合更好用
→ StupidGaGa:容易維護不是沒標準,只是沒人重視
→ StupidGaGa:在iPhone出來前，有多少人不重視直覺式UI？
推 f1234518456:沒事不要動 早點回家最好
→ StupidGaGa:容易維護就如同我上述所說的兩點
→ StupidGaGa:1. 直覺式架構、程式碼 2. 程式獨立性高,可簡易刪增
→ eva19452002:我以為容易維護應該是指 1.藕合性弱，內聚力強
→ eva19452002:2.變數和func名稱有意義
推 CGary:其實光是一直直覺式架構就有得吵了...
→ CGary:隨著學的東西背景不同 信仰不同 你認為直覺的東西別人覺得
→ CGary:累贅的多有人在,就像我之前說的:沒壞的東西別沒事亂修...
→ CGary:容易維護說來沒有標準 但有一個原則: 就是少用高超的技巧...
→ bobju:看到[直覺]就害怕~你做得流血流汗,我[直覺]就是不喜歡 ~_~
→ bobju:問:你這架構怎麼來的? 答:憑我的設計直覺來的. <-退件,回去
→ bobju:研究清楚再重新提案