[請益] 會花時間改自己以前的爛帳嗎?已刪文

看板Soft_Job作者 (kkk)時間5年前 (2019/01/07 18:54), 編輯推噓29(32321)
留言56則, 40人參與, 5年前最新討論串1/2 (看更多)
跟著一個專案走4年了 當初從無到有打了一段爛帳 現在持續維護跟開發新功能 每每看到以前留下的爛坑 就很不好意思 沒封裝,沒多型 一堆程式碼糾纏在一起 有時想動手重構 又想到現在上commit,很多人會review 也不知適不適合改動已經上線已久的專案 你們會花費力氣去修改以前的爛坑嗎? -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 101.12.182.158 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1546858464.A.2AF.html

01/07 18:59, 5年前 , 1F
01/07 18:59, 1F

01/07 19:00, 5年前 , 2F
會啊 人要對自己負責
01/07 19:00, 2F

01/07 19:04, 5年前 , 3F
看上面,上面不支持,你改了搞不好怪你沒事找事XD
01/07 19:04, 3F

01/07 19:11, 5年前 , 4F
對 先問主管 不給時間或不在乎 就放給他爛就好
01/07 19:11, 4F

01/07 19:15, 5年前 , 5F
上面同意就會
01/07 19:15, 5F

01/07 19:40, 5年前 , 6F
同意,如果有時間允許,還是重構一下好。
01/07 19:40, 6F

01/07 19:40, 5年前 , 7F
不然那天新需求或修改需求動到那坑更痛苦
01/07 19:40, 7F

01/07 19:46, 5年前 , 8F
先算成本; 規模太大, Netscape 5 的教訓被歷史銘記
01/07 19:46, 8F

01/07 19:48, 5年前 , 9F
先寫測試
01/07 19:48, 9F

01/07 20:23, 5年前 , 10F
問題是沒有時間 (?
01/07 20:23, 10F

01/07 21:07, 5年前 , 11F
"上線已久的專案" 沒必要
01/07 21:07, 11F

01/07 21:10, 5年前 , 12F
有狀況需要修改的時候再來重構。沒問題好好的幹嘛改?
01/07 21:10, 12F

01/07 21:31, 5年前 , 13F
千萬不要,除非公司要你去重構,不然上線中的東西別亂動
01/07 21:31, 13F

01/07 21:32, 5年前 , 14F
01/07 21:32, 14F

01/07 22:02, 5年前 , 15F
推樓樓上,上線後,穩定的程式碼比乾淨的程式碼重要
01/07 22:02, 15F

01/07 22:02, 5年前 , 16F
太多
01/07 22:02, 16F

01/07 22:45, 5年前 , 17F
會阿,如果有人會看,你就本地端開分支改就好
01/07 22:45, 17F

01/07 22:46, 5年前 , 18F
新功能/新專案可以做, 但舊架構變新架構 心臟要很大顆
01/07 22:46, 18F

01/07 23:22, 5年前 , 19F
剛好有 bug 或擴充就順便改,不然就丟著
01/07 23:22, 19F

01/07 23:51, 5年前 , 20F
不用刻意改,但如果在做新專案會用到或改到那塊程式,就
01/07 23:51, 20F

01/07 23:51, 5年前 , 21F
會順手做
01/07 23:51, 21F

01/07 23:55, 5年前 , 22F
尤其是重複的 一定想辦法消滅
01/07 23:55, 22F

01/07 23:55, 5年前 , 23F
遇過太多擺爛 視而不見,又複製一份來改 久而久之都不知
01/07 23:55, 23F

01/07 23:55, 5年前 , 24F
道是刻意還是漏改的 接手時幹死
01/07 23:55, 24F

01/08 00:04, 5年前 , 25F
先補test 再來修改
01/08 00:04, 25F

01/08 00:36, 5年前 , 26F
上線的還改? 成本非常高 你還要把測試sit uat重跑一輪
01/08 00:36, 26F

01/08 02:28, 5年前 , 27F
你又不像其他高手改了不會有bug,問了也沒個屁用
01/08 02:28, 27F

01/08 02:49, 5年前 , 28F
我們公司的senior還蠻常refactoring 不過真的要好好測試
01/08 02:49, 28F

01/08 02:50, 5年前 , 29F
以前待工廠的MIS 老闆是不鼓勵重構的 產業不同觀念不同
01/08 02:50, 29F

01/08 04:13, 5年前 , 30F
沒必要,真的閒到不行也是從有test的專案開始
01/08 04:13, 30F

01/08 06:51, 5年前 , 31F
已經MP就不要,跨很恐怖
01/08 06:51, 31F

01/08 09:00, 5年前 , 32F
沒寫測試 重構找自己麻煩
01/08 09:00, 32F

01/08 09:09, 5年前 , 33F
refactoring 也要有適當的資源,如果什麼測試都沒有,這
01/08 09:09, 33F

01/08 09:09, 5年前 , 34F
個專案也上線了且更動幅度不高,風險衡量下來可能不要動
01/08 09:09, 34F

01/08 09:09, 5年前 , 35F
還好一點。重構也是有成本和風險的啊。
01/08 09:09, 35F

01/08 09:19, 5年前 , 36F
一定要有配套的測試才改。不然下場是自己很有自信的認
01/08 09:19, 36F

01/08 09:19, 5年前 , 37F
為只是改寫法,不會有問題,但卻壞了
01/08 09:19, 37F

01/08 09:47, 5年前 , 38F
用OOP 才是在製造爛 code 吧!
01/08 09:47, 38F

01/08 10:48, 5年前 , 39F
沒事不要改
01/08 10:48, 39F

01/08 11:19, 5年前 , 40F
令人懷念的神奇id又出現惹
01/08 11:19, 40F

01/08 11:21, 5年前 , 41F
用oop是製造爛code? 那是不會用亂用吧
01/08 11:21, 41F

01/08 13:11, 5年前 , 42F
沒必要 時間到了砍掉重練就好 就像windows一樣
01/08 13:11, 42F

01/08 14:13, 5年前 , 43F
當然會啊 不然黑歷史太多怎麼出來混
01/08 14:13, 43F

01/08 16:03, 5年前 , 44F
會 但是要看工作有沒有被排滿
01/08 16:03, 44F

01/08 16:17, 5年前 , 45F
01/08 16:17, 45F

01/09 01:44, 5年前 , 46F
以後寫漂亮點就好了 舊的東西能動 效能沒問題就不要動吧
01/09 01:44, 46F

01/09 01:44, 5年前 , 47F
01/09 01:44, 47F

01/09 07:39, 5年前 , 48F
真的想改您要先把每一個步驟寫出來 寫到很細節 然後給
01/09 07:39, 48F

01/09 07:39, 5年前 , 49F
主管看 請他背書
01/09 07:39, 49F

01/09 07:40, 5年前 , 50F
我的經驗是極其困難 所有之前該測的都要測到 所以要有
01/09 07:40, 50F

01/09 07:40, 5年前 , 51F
不錯的自動測試 跟benchmark 才能保證改好的跟原來一
01/09 07:40, 51F

01/09 07:40, 5年前 , 52F
樣能動
01/09 07:40, 52F

01/09 18:26, 5年前 , 53F
如果知道所有邏輯就動,不知道就先不動
01/09 18:26, 53F

01/09 23:16, 5年前 , 54F
同MixBear
01/09 23:16, 54F

01/12 15:51, 5年前 , 55F
有時間會改,問題是沒時間
01/12 15:51, 55F

01/20 10:29, 5年前 , 56F
會改
01/20 10:29, 56F
文章代碼(AID): #1SCo_WAl (Soft_Job)
文章代碼(AID): #1SCo_WAl (Soft_Job)