PTT職涯區 / Soft_Job (軟體人)

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

看板Soft_Job (軟體人)作者 (累人啊....)時間12年前 (2013/07/24 14:55), 編輯推噓19(19推 0噓 108→)
留言127則, 21人參與, 最新討論串1/10 (看更多)
如題,因為不知道適合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)
→
07/24 15:08, , 1F
看this就夠了連屬性都不用吧?
07/24 15:08, 1F
推
07/24 15:18, , 2F
branch 出來試吧？ 感覺一天就可以改完了。
07/24 15:18, 2F
→
07/24 15:19, , 3F
大概幾小時內的事情吧..
07/24 15:19, 3F
→
07/24 15:20, , 4F
確定流程, 程式搬一搬應該就結束了
07/24 15:20, 4F
→
07/24 15:36, , 5F
程式的維護性與簡便性相衝突
07/24 15:36, 5F
→
07/24 15:39, , 6F
我覺得除非有特殊需求，否則請以"容易維護"為最高標準
07/24 15:39, 6F
→
07/24 15:40, , 7F
你要了解，也許你走了，接手你工作的人是否容易上手？
07/24 15:40, 7F
→
07/24 15:45, , 8F
今天你看懂前任的程式，但下任是否看得懂你的程式？
07/24 15:45, 8F
推
07/24 16:15, , 9F
同意樓上
07/24 16:15, 9F
→
07/24 16:18, , 10F
不同意GaGa, 因為"容易維護"沒有標準
07/24 16:18, 10F
→
07/24 16:18, , 11F
你永遠不知道之後接手的是神一樣的高手, 還是....
07/24 16:18, 11F
→
07/24 16:19, , 12F
你可以試試看, 寫完多驗一驗看會不會遇到問題
07/24 16:19, 12F
→
07/24 16:20, , 13F
只要確認不影響結果, 改好了老板也不會有意見
07/24 16:20, 13F
推
07/24 16:21, , 14F
為什么會難以區分，CallStack不是可以看出來嗎？
07/24 16:21, 14F
→
07/24 16:21, , 15F
寫程式不要怕出錯, 怕出錯建議左轉去考鐵飯碗
07/24 16:21, 15F
→
07/24 16:25, , 16F
copy&paste code絕對不是什麼容易維護的東西
07/24 16:25, 16F
→
07/24 16:25, , 17F
哪天需要改他就頭大了
07/24 16:25, 17F
推
07/24 16:27, , 18F
程式的原作者可以問嗎?如果這是一個不算簡單的程式,那它的
07/24 16:27, 18F
→
07/24 16:28, , 19F
作者應該不會比你兩光多少, 你自己也說這樣改不算小改
07/24 16:28, 19F
→
07/24 16:29, , 20F
那就表示這樣寫是有它的原因的. 或許初期規劃沒有做的很好
07/24 16:29, 20F
→
07/24 16:30, , 21F
但是多線緒把callee統一拉出來絕對會有一鑼匡雞飛狗跳的問
07/24 16:30, 21F
→
07/24 16:31, , 22F
題,除非你全懂,要不然你永遠不知道哪邊藏個race condition
07/24 16:31, 22F
→
07/24 16:31, , 23F
的問題,小則crash,大則bug完全抓不出要怎樣改
07/24 16:31, 23F
→
07/24 16:36, , 24F
我覺得這程式的規模不大,但對於社會新鮮人來說,算大
07/24 16:36, 24F
→
07/24 16:37, , 25F
而因為若作這樣的修改,是"數個class"都要作修改
07/24 16:37, 25F
→
07/24 16:37, , 26F
對於"公司"來說,這是個風險,所以我才沒有先幹再說的想法
07/24 16:37, 26F
→
07/24 16:38, , 27F
但我也不覺得這樣的修改要花我多少時間,只是單純主管不贊
07/24 16:38, 27F
→
07/24 16:38, , 28F
所以就提出來聽聽大家怎麼想
07/24 16:38, 28F
→
07/24 16:40, , 29F
我對容易維護的定義很簡單 1. 直覺式的了解程式
07/24 16:40, 29F
→
07/24 16:40, , 30F
2. 獨立性夠好
07/24 16:40, 30F
→
07/24 16:42, , 31F
如果以原PO的方式，假設要做個別化的處理，就很麻煩
07/24 16:42, 31F
→
07/24 16:42, , 32F
如果以原本程式，我只要針對那個class下去做處理
07/24 16:42, 32F
→
07/24 16:43, , 33F
寫程式除非真的有特別的需求，不然請"容易維護"當基礎
07/24 16:43, 33F
→
07/24 16:45, , 34F
你要有個自覺，老闆可能會要求你改功能
07/24 16:45, 34F
→
07/24 16:46, , 35F
如果今天程式100年都不會變，老闆都不會要求你更改功能
07/24 16:46, 35F
→
07/24 16:46, , 36F
我會採用你的做法，但是現實生活是，老闆常常要求改變
07/24 16:46, 36F
→
07/24 16:47, , 37F
如果你程式獨立性不夠，牽一髮動全身，你會死得很慘
07/24 16:47, 37F
→
07/24 16:48, , 38F
我語重心長的說，請不要把程式寫成BIOS的恐龍時代
07/24 16:48, 38F
→
07/24 16:49, , 39F
連BIOS的恐龍都滅絕了，為什麼高階語言還要寫成那樣？
07/24 16:49, 39F
還有 48 則推文
→
07/24 18:21, , 88F
但是就是會有笨蛋把看起來很像但其實不一樣的東西拿來「重構
07/24 18:21, 88F
→
07/24 18:22, , 89F
」然後就爆了，或是以為可以少跑幾個迴圈之類的"優化"。
07/24 18:22, 89F
→
07/24 18:22, , 90F
原 po 到底是怎麼樣我覺得不用多作臆測啦，但是有修改一定要
07/24 18:22, 90F
→
07/24 18:23, , 91F
把所有會跑過那段 code 的地方前因後果看仔細，這是基本禮貌
07/24 18:23, 91F
→
07/24 18:23, , 92F
千萬不要想當然爾的"看起來一樣"，所以就沒測，會死人的。
07/24 18:23, 92F
→
07/24 18:24, , 93F
我不是「程式碼沒壞就別去動他」的信徒，我也會大改系統核心
07/24 18:24, 93F
→
07/24 18:25, , 94F
，我信奉的是「要改就要認真讀原本的 code、要改就要測試」
07/24 18:25, 94F
推
07/24 21:09, , 95F
要改可以,不過你在提案時要有足夠的誘因打動主管支持,不然就
07/24 21:09, 95F
→
07/24 21:09, , 96F
是時機未到,多一事不如少一事
07/24 21:09, 96F
→
07/24 21:42, , 97F
這個就解了 http://ppt.cc/vzjO
07/24 21:42, 97F
→
07/24 22:03, , 98F
有先從商業邏輯來看嗎?如果沒有~很可能它的用法跟你想的不
07/24 22:03, 98F
→
07/24 22:03, , 99F
一樣~如果是這樣~很可能它本來就該是個別處理...
07/24 22:03, 99F
推
07/24 22:37, , 100F
隨便亂改再加個 //Magic, DO NOT touch就好了
07/24 22:37, 100F
推
07/24 22:42, , 101F
If it ain't broke, don't fix it
07/24 22:42, 101F
→
07/24 22:43, , 102F
除非你還要針對這些程式做甚麼額外的事情 否則沒事找事改完
07/24 22:43, 102F
→
07/24 22:43, , 103F
萬一將來出現bug, 甚麼事情都會直接扯上你今日動手修他的這
07/24 22:43, 103F
→
07/24 22:44, , 104F
件事情 而且既然容易維護沒標準 只要不是非常髒的code 不用
07/24 22:44, 104F
→
07/24 22:44, , 105F
特別拉他出來做一個 interface...
07/24 22:44, 105F
推
07/25 00:02, , 106F
請教一下 為什麼不直接做繼承 還要先做個interface 做個
07/25 00:02, 106F
→
07/25 00:04, , 107F
類別實作後，再原本的兩個類別繼承這個時做interdace的
07/25 00:04, 107F
→
07/25 00:04, , 108F
類別，趁這個機會也讓我偷學一下 @@
07/25 00:04, 108F
→
07/25 00:07, , 109F
在此也順便分享我的經驗，如果這個FUN是核心函式(重要)
07/25 00:07, 109F
→
07/25 00:07, , 110F
除非他有BUG不然我不會動，除此之外 為了程式的可維護性
07/25 00:07, 110F
→
07/25 00:08, , 111F
我會直接就下手囉~~
07/25 00:08, 111F
→
07/25 00:09, , 112F
這邊應該是指 base class
07/25 00:09, 112F
→
07/25 00:13, , 113F
繼承好用,但是在大部分的情況下，組合更好用
07/25 00:13, 113F
→
07/25 00:14, , 114F
容易維護不是沒標準,只是沒人重視
07/25 00:14, 114F
→
07/25 00:15, , 115F
在iPhone出來前，有多少人不重視直覺式UI？
07/25 00:15, 115F
推
07/25 00:15, , 116F
沒事不要動 早點回家最好
07/25 00:15, 116F
→
07/25 00:16, , 117F
容易維護就如同我上述所說的兩點
07/25 00:16, 117F
→
07/25 00:17, , 118F
1. 直覺式架構、程式碼 2. 程式獨立性高,可簡易刪增
07/25 00:17, 118F
→
07/25 06:06, , 119F
我以為容易維護應該是指 1.藕合性弱，內聚力強
07/25 06:06, 119F
→
07/25 06:06, , 120F
2.變數和func名稱有意義
07/25 06:06, 120F
推
07/25 12:14, , 121F
其實光是一直直覺式架構就有得吵了...
07/25 12:14, 121F
→
07/25 12:15, , 122F
隨著學的東西背景不同 信仰不同 你認為直覺的東西別人覺得
07/25 12:15, 122F
→
07/25 12:16, , 123F
累贅的多有人在,就像我之前說的:沒壞的東西別沒事亂修...
07/25 12:16, 123F
→
07/25 12:17, , 124F
容易維護說來沒有標準 但有一個原則: 就是少用高超的技巧...
07/25 12:17, 124F
→
07/25 14:53, , 125F
看到[直覺]就害怕~你做得流血流汗,我[直覺]就是不喜歡 ~_~
07/25 14:53, 125F
→
07/25 14:54, , 126F
問:你這架構怎麼來的? 答:憑我的設計直覺來的. <-退件,回去
07/25 14:54, 126F
→
07/25 14:54, , 127F
研究清楚再重新提案
07/25 14:54, 127F
‣ 更多 tyc5116 的文章
文章代碼(AID): #1HxtfqaA (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 10 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共10篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 tyc5116 的文章
文章代碼(AID): #1HxtfqaA (Soft_Job)