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

[srwhite (阿白)]

事情是這樣的

小弟最近接到使用者需求

要增加幾個跟之前很像的功能


舊的那隻程式已經歷經許多測試  目前正穩定的運作中

但最初的需求很單純

因此設計得不是很有彈性 不利於擴充及更改



第一次接到需求的時候

我想了一下覺得重構有點麻煩

於是直接複製了一份然後改了需要改的地方

變成兩隻有八成像的程式 各做各的


但最近又要再增加一個

於是我開始猶豫該不該整個打掉重構

避免程式碼繼續這樣擴張下去 感覺很不專業

之後再有需求也比較好調整


但如果複製改一改大概只要一個小時

打掉重構可能要一個禮拜 還不保證會不會有甚麼多出來的bug



想請教大家在類似的情況

都用哪些標準來決定甚麼時候應該重構

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.34.156.195
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1541959482.A.056.html
→ kissmickey: 上面看你沒事找事做的時候
→ alog: 做事情是這樣 如果你覺得某些事你這樣做可以省到後面很多時
→ alog: 間你可以做 但實際效果沒有符合預期/有機會搞砸/婊到別人/
→ alog: 自己扛責/你沒有你想像中的專業有把握 你就不該隨便亂動已經
→ alog: 跑的很穩定的東西
→ alog: 還有不要用感覺來判斷專不專業 應該要仔細分析優缺點再來抓
→ alog: 一個正確的作法
推 gs8613789: 沒事做的時候
推 Masakiad: 你的狀況應該是因為沒寫測試案例才會覺得重構容易有bug
推 t64141: 維護越來越痛苦的時候
推 ripple0129: 寫久了都會有感覺哪邊是應該要事先提出來復用的部分，
→ ripple0129: 很不科學但是真的是很吃肌肉記憶
→ ripple0129: 抽象一點的說就是會自動分類可變動與不可變動的部分吧
推 s89162504: 千萬不要refactor 除非你吃飽了沒事幹
→ t64141: 然後不要習慣複製貼上改一行，很可怕
推 Argos: 看了上面一堆人排斥重構 就知道台灣軟體業只會繼續腐爛
推 MixBear: 重構是持續進行的 比如你現在這時候遇到這狀況 就要拉正
→ MixBear: ，而不是持續放任歪樓
→ Argos: 重構這種事有時根本就舉手之勞而已 順手改一點改一點
→ Argos: 老實說 會不會想去重構 跟工程師自身的修養有很大的關係
→ Argos: 你夠不夠認真看待你的專業 就決定你對重構的態度
→ Argos: 回到現實面 你要重構當然要跟上級討論並且獲得許可及時間
→ Argos: 如果上面管理方都同意 你當然應該要開始重構
→ Argos: 但這件事應該是由工程師自己發現問題 並主動向上面提出
推 MixBear: 最討厭維護複製貼上一堆相似程式，然後同樣邏輯要改漏東
→ MixBear: 漏西的
→ Argos: 如果上面死都不願給時程 那你還有藉口讓它放著爛沒關係
推 MixBear: 造成後人不便，自己也常埋地雷的程式片段
→ Argos: 而不是聽到要改Legacy就避之為恐不及
推 menshuei: 大部分只會重建不會重構。
→ Argos: 我講的是態度方面 至於執行細節 原本Legacy連測試都沒 怎麼
→ Argos: 改 嚴格來說都不算是重構就是了 XD
推 ghmsxtwo: 離職前
推 benqm300: http://i.imgur.com/i6k6k2F.jpg
→ x000032001: 推文就推文 推一張圖幹嘛？
→ benqm300: 字太多有時會被切斷跳行
噓 alihue: 一堆人排斥重構，然後又嫌台灣軟體業爛
→ alihue: 反正到最後也是牽拖到老闆，不檢討自己
→ alihue: 市面上很多重構的方法，包含寫完整的測試與ci/cd，確定你
→ alihue: 在可控的風險下重構。不重構只會讓後人東補西補，踩地雷
→ alihue: 讓台灣的軟體缺一個比一個還屎
→ vi000246: 重構沒那麼簡單 做得好沒人理 出錯被釘到死
→ vi000246: 這是政治問題 不是軟體問題
推 devilkool: 新學到東西然後想起過去的code寫得有夠爛時
推 cphe: 打掉重練政治問題比較多，做久就知道為什麼，有時候不是你想
→ cphe: 做就有辦法執行
→ cphe: 除非上面決策的人打從心裡想這麼做
→ testPtt: 重構最基本要有明確的spec
→ IDL: 想離職時
→ alihue: 重構是一群小修改的集合...稍微抽出method或rename都算
推 alihue: https://martinfowler.com/books/refactoring.html
→ alihue: 雖然繁中譯本已經絕版，但簡體書大家也可以加減看一下
→ alihue: 作者就是定義重構的人
→ alihue: Its essence is applying a series of small
→ alihue: behavior-preserving transformations, each of which
→ alihue:  "too small to be worth doing".
→ vi000246: 我是會考慮重構對我是否Z>B 如果以後能省很多時間
→ vi000246: 我就會重構 而不是以公司角度考量
推 Argos: 政治的確才是真正的問題 但我上面在說的是工程師本身的態度
→ Argos: 一堆人就是寧可放在那邊爛也不想去動 甚至上面給你時間叫你
→ Argos: 改你都千推萬推找一堆藉口 這種就是垃圾 軟體界的毒瘤
→ Argos: 你想重構但上面不給你時間和資源那就算了阿 至少你提過了
→ Argos: 有想要重構的態度出來就行了 至少在這種心態下 你新產出的
→ Argos: 程式不會差到哪裡去 因為過去的垃圾你都看不順眼了
→ Argos: 但如果懶得去管過去垃圾 那非常有可能未來也是繼續出垃圾
推 a926: 重構很難？
→ alog: 沒有人排斥重構 是你本不該就隨便亂動已經final的code 這種
→ alog: 都是團體內有共同共識考量到長期維護同案/持續上線營運的才
→ alog: 會慢慢修改 你一人專案或完全你負責要怎樣改都是你的事
→ alog: 只要是在合理的時間範圍完成你要自high/練功都行
→ alog: 重構都是會發生在有必要做的時候 而有必要做的時機是在你真
→ alog: 的有看到明確的問題時候
→ alog: 你知道怎麼改比較正確 跟獲得更大效益
→ alog: 不是你在那裡自high想改就在那裡下刀動手
→ alog: 小弟做系統幫專案做重構改了數百組核心也寫了數百組測試不
→ alog: 知道這個心得不知道夠不夠格
→ alog: 上次一位只是改個function覺得沒問題也測過了上線直接當天
→ alog: 飛起來 你以為沒壓力啊
→ robber1234: 加薪的時候
→ alog: 我剛好朋友也有主力的產品 一個系統的營收是用千萬在計算 開
→ alog: 個 Basecamp 看到滿滿記載要重構的地方 都是有原因跟理由的
→ alog: 真的從來沒看過用感覺在做事 幹這件事的人已經飛上去了
→ alog: (上述那位）
→ massrelay: 需要花多久時間才是重點
推 diabloevagto: 要離職的時候，重構爆掉就不用救了
推 iamshiao: 隨時
推 SHANGOYANYI: cp改一改就好了 別沒事找事 沒人會感謝你的
推 YAYA6655: 退休後
推 clamperni: 神明託夢說改就改
推 solonwu: 有把握不會出包的話我會重構
→ windlll: 舊的不動，新的慢慢寫，然後拿之前的test跑三次
→ windlll: 確定沒問題後才拿出來
推 new122851: 自己的扣才會  別人的扣一不小心沒用好 自找麻煩
推 ppHomer: 重構有很多層次 只是約分/提出一個共用的func 也算重構
→ ppHomer: 將某變數或函式 rename成比較有意義看得懂的名稱也是重構
→ ppHomer: 將重覆出現的字串 改成const variable來使用也是重構
→ ppHomer: 雖然都是小小的整理 都算是重構, 也都需要進行測試
→ vul3kuo: 長官看你都準時下班的時候
→ bobju: 既然你會猶豫,那就是想得不夠徹底,想到你決定要做(或不要),
→ bobju: 那就對了
推 tvbic: Never
→ loadingN: 吃飽太閒? 自己開個branch去玩啦
推 lnmlee: 你想要長期領養這隻野貓的時候你就會想為他洗澡
推 ak2840: 打掉就不是重構了 那是重練
噓 THEWORLDS: 複製一份
→ lp2650056: 大程式重構...？呵呵