PTT職涯區 / Soft_Job (軟體人)

[請益] 何時會決定要重構程式

看板Soft_Job (軟體人)作者 (阿白)時間7年前 (2018/11/12 02:04), 編輯推噓26(28推 2噓 76→)
留言106則, 39人參與, 7年前最新討論串1/5 (看更多)
事情是這樣的 小弟最近接到使用者需求 要增加幾個跟之前很像的功能 舊的那隻程式已經歷經許多測試 目前正穩定的運作中 但最初的需求很單純 因此設計得不是很有彈性 不利於擴充及更改 第一次接到需求的時候 我想了一下覺得重構有點麻煩 於是直接複製了一份然後改了需要改的地方 變成兩隻有八成像的程式 各做各的 但最近又要再增加一個 於是我開始猶豫該不該整個打掉重構 避免程式碼繼續這樣擴張下去 感覺很不專業 之後再有需求也比較好調整 但如果複製改一改大概只要一個小時 打掉重構可能要一個禮拜 還不保證會不會有甚麼多出來的bug 想請教大家在類似的情況 都用哪些標準來決定甚麼時候應該重構 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.34.156.195 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1541959482.A.056.html
→
11/12 02:20, 7年前 , 1F
上面看你沒事找事做的時候
11/12 02:20, 1F
→
11/12 02:26, 7年前 , 2F
做事情是這樣 如果你覺得某些事你這樣做可以省到後面很多時
11/12 02:26, 2F
→
11/12 02:26, 7年前 , 3F
間你可以做 但實際效果沒有符合預期/有機會搞砸/婊到別人/
11/12 02:26, 3F
→
11/12 02:26, 7年前 , 4F
自己扛責/你沒有你想像中的專業有把握 你就不該隨便亂動已經
11/12 02:26, 4F
→
11/12 02:26, 7年前 , 5F
跑的很穩定的東西
11/12 02:26, 5F
→
11/12 02:28, 7年前 , 6F
還有不要用感覺來判斷專不專業 應該要仔細分析優缺點再來抓
11/12 02:28, 6F
→
11/12 02:28, 7年前 , 7F
一個正確的作法
11/12 02:28, 7F
推
11/12 08:25, 7年前 , 8F
沒事做的時候
11/12 08:25, 8F
推
11/12 08:36, 7年前 , 9F
你的狀況應該是因為沒寫測試案例才會覺得重構容易有bug
11/12 08:36, 9F
推
11/12 09:04, 7年前 , 10F
維護越來越痛苦的時候
11/12 09:04, 10F
推
11/12 09:06, 7年前 , 11F
寫久了都會有感覺哪邊是應該要事先提出來復用的部分，
11/12 09:06, 11F
→
11/12 09:06, 7年前 , 12F
很不科學但是真的是很吃肌肉記憶
11/12 09:06, 12F
→
11/12 09:08, 7年前 , 13F
抽象一點的說就是會自動分類可變動與不可變動的部分吧
11/12 09:08, 13F
推
11/12 09:09, 7年前 , 14F
千萬不要refactor 除非你吃飽了沒事幹
11/12 09:09, 14F
→
11/12 09:21, 7年前 , 15F
然後不要習慣複製貼上改一行，很可怕
11/12 09:21, 15F
推
11/12 09:41, 7年前 , 16F
看了上面一堆人排斥重構 就知道台灣軟體業只會繼續腐爛
11/12 09:41, 16F
推
11/12 09:41, 7年前 , 17F
重構是持續進行的 比如你現在這時候遇到這狀況 就要拉正
11/12 09:41, 17F
→
11/12 09:41, 7年前 , 18F
，而不是持續放任歪樓
11/12 09:41, 18F
→
11/12 09:42, 7年前 , 19F
重構這種事有時根本就舉手之勞而已 順手改一點改一點
11/12 09:42, 19F
→
11/12 09:43, 7年前 , 20F
老實說 會不會想去重構 跟工程師自身的修養有很大的關係
11/12 09:43, 20F
→
11/12 09:43, 7年前 , 21F
你夠不夠認真看待你的專業 就決定你對重構的態度
11/12 09:43, 21F
→
11/12 09:44, 7年前 , 22F
回到現實面 你要重構當然要跟上級討論並且獲得許可及時間
11/12 09:44, 22F
→
11/12 09:44, 7年前 , 23F
如果上面管理方都同意 你當然應該要開始重構
11/12 09:44, 23F
→
11/12 09:44, 7年前 , 24F
但這件事應該是由工程師自己發現問題 並主動向上面提出
11/12 09:44, 24F
推
11/12 09:45, 7年前 , 25F
最討厭維護複製貼上一堆相似程式，然後同樣邏輯要改漏東
11/12 09:45, 25F
→
11/12 09:45, 7年前 , 26F
漏西的
11/12 09:45, 26F
→
11/12 09:45, 7年前 , 27F
如果上面死都不願給時程 那你還有藉口讓它放著爛沒關係
11/12 09:45, 27F
推
11/12 09:46, 7年前 , 28F
造成後人不便，自己也常埋地雷的程式片段
11/12 09:46, 28F
→
11/12 09:47, 7年前 , 29F
而不是聽到要改Legacy就避之為恐不及
11/12 09:47, 29F
推
11/12 09:47, 7年前 , 30F
大部分只會重建不會重構。
11/12 09:47, 30F
→
11/12 09:48, 7年前 , 31F
我講的是態度方面 至於執行細節 原本Legacy連測試都沒 怎麼
11/12 09:48, 31F
→
11/12 09:48, 7年前 , 32F
改 嚴格來說都不算是重構就是了 XD
11/12 09:48, 32F
推
11/12 09:49, 7年前 , 33F
離職前
11/12 09:49, 33F
推
11/12 09:59, 7年前 , 34F
11/12 09:59, 34F
→
11/12 10:16, 7年前 , 35F
推文就推文 推一張圖幹嘛？
11/12 10:16, 35F
→
11/12 10:19, 7年前 , 36F
字太多有時會被切斷跳行
11/12 10:19, 36F
噓
11/12 10:40, 7年前 , 37F
一堆人排斥重構，然後又嫌台灣軟體業爛
11/12 10:40, 37F
→
11/12 10:41, 7年前 , 38F
反正到最後也是牽拖到老闆，不檢討自己
11/12 10:41, 38F
→
11/12 10:42, 7年前 , 39F
市面上很多重構的方法，包含寫完整的測試與ci/cd，確定你
11/12 10:42, 39F
還有 27 則推文
→
11/12 13:33, 7年前 , 67F
沒有人排斥重構 是你本不該就隨便亂動已經final的code 這種
11/12 13:33, 67F
→
11/12 13:33, 7年前 , 68F
都是團體內有共同共識考量到長期維護同案/持續上線營運的才
11/12 13:33, 68F
→
11/12 13:33, 7年前 , 69F
會慢慢修改 你一人專案或完全你負責要怎樣改都是你的事
11/12 13:33, 69F
→
11/12 13:34, 7年前 , 70F
只要是在合理的時間範圍完成你要自high/練功都行
11/12 13:34, 70F
→
11/12 13:37, 7年前 , 71F
重構都是會發生在有必要做的時候 而有必要做的時機是在你真
11/12 13:37, 71F
→
11/12 13:37, 7年前 , 72F
的有看到明確的問題時候
11/12 13:37, 72F
→
11/12 13:37, 7年前 , 73F
你知道怎麼改比較正確 跟獲得更大效益
11/12 13:37, 73F
→
11/12 13:38, 7年前 , 74F
不是你在那裡自high想改就在那裡下刀動手
11/12 13:38, 74F
→
11/12 13:39, 7年前 , 75F
小弟做系統幫專案做重構改了數百組核心也寫了數百組測試不
11/12 13:39, 75F
→
11/12 13:39, 7年前 , 76F
知道這個心得不知道夠不夠格
11/12 13:39, 76F
→
11/12 13:40, 7年前 , 77F
上次一位只是改個function覺得沒問題也測過了上線直接當天
11/12 13:40, 77F
→
11/12 13:40, 7年前 , 78F
飛起來 你以為沒壓力啊
11/12 13:40, 78F
→
11/12 13:41, 7年前 , 79F
加薪的時候
11/12 13:41, 79F
→
11/12 13:42, 7年前 , 80F
我剛好朋友也有主力的產品 一個系統的營收是用千萬在計算 開
11/12 13:42, 80F
→
11/12 13:42, 7年前 , 81F
個 Basecamp 看到滿滿記載要重構的地方 都是有原因跟理由的
11/12 13:42, 81F
→
11/12 13:43, 7年前 , 82F
真的從來沒看過用感覺在做事 幹這件事的人已經飛上去了
11/12 13:43, 82F
→
11/12 13:43, 7年前 , 83F
(上述那位）
11/12 13:43, 83F
→
11/12 14:19, 7年前 , 84F
需要花多久時間才是重點
11/12 14:19, 84F
推
11/12 18:11, 7年前 , 85F
要離職的時候，重構爆掉就不用救了
11/12 18:11, 85F
推
11/12 18:12, 7年前 , 86F
隨時
11/12 18:12, 86F
推
11/12 18:53, 7年前 , 87F
cp改一改就好了 別沒事找事 沒人會感謝你的
11/12 18:53, 87F
推
11/12 22:06, 7年前 , 88F
退休後
11/12 22:06, 88F
推
11/12 22:14, 7年前 , 89F
神明託夢說改就改
11/12 22:14, 89F
推
11/12 22:39, 7年前 , 90F
有把握不會出包的話我會重構
11/12 22:39, 90F
→
11/12 23:09, 7年前 , 91F
舊的不動，新的慢慢寫，然後拿之前的test跑三次
11/12 23:09, 91F
→
11/12 23:09, 7年前 , 92F
確定沒問題後才拿出來
11/12 23:09, 92F
推
11/13 00:21, 7年前 , 93F
自己的扣才會 別人的扣一不小心沒用好 自找麻煩
11/13 00:21, 93F
推
11/13 11:50, 7年前 , 94F
重構有很多層次 只是約分/提出一個共用的func 也算重構
11/13 11:50, 94F
→
11/13 11:53, 7年前 , 95F
將某變數或函式 rename成比較有意義看得懂的名稱也是重構
11/13 11:53, 95F
→
11/13 11:54, 7年前 , 96F
將重覆出現的字串 改成const variable來使用也是重構
11/13 11:54, 96F
→
11/13 11:56, 7年前 , 97F
雖然都是小小的整理 都算是重構, 也都需要進行測試
11/13 11:56, 97F
→
11/13 13:27, 7年前 , 98F
長官看你都準時下班的時候
11/13 13:27, 98F
→
11/13 15:45, 7年前 , 99F
既然你會猶豫,那就是想得不夠徹底,想到你決定要做(或不要),
11/13 15:45, 99F
→
11/13 15:45, 7年前 , 100F
那就對了
11/13 15:45, 100F
推
11/13 19:43, 7年前 , 101F
Never
11/13 19:43, 101F
→
11/14 01:15, 7年前 , 102F
吃飽太閒? 自己開個branch去玩啦
11/14 01:15, 102F
推
11/15 15:10, 7年前 , 103F
你想要長期領養這隻野貓的時候你就會想為他洗澡
11/15 15:10, 103F
推
11/16 14:46, 7年前 , 104F
打掉就不是重構了 那是重練
11/16 14:46, 104F
噓
11/18 09:33, 7年前 , 105F
複製一份
11/18 09:33, 105F
→
11/26 16:08, 7年前 , 106F
大程式重構...？呵呵
11/26 16:08, 106F
‣ 更多 srwhite 的文章
文章代碼(AID): #1Rw6yw1M (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 srwhite 的文章
文章代碼(AID): #1Rw6yw1M (Soft_Job)