作者:
srwhite (魯蛇阿白)
2018-11-12 02:04:38事情是這樣的
小弟最近接到使用者需求
要增加幾個跟之前很像的功能
舊的那隻程式已經歷經許多測試 目前正穩定的運作中
但最初的需求很單純
因此設計得不是很有彈性 不利於擴充及更改
第一次接到需求的時候
我想了一下覺得重構有點麻煩
於是直接複製了一份然後改了需要改的地方
變成兩隻有八成像的程式 各做各的
但最近又要再增加一個
於是我開始猶豫該不該整個打掉重構
避免程式碼繼續這樣擴張下去 感覺很不專業
之後再有需求也比較好調整
但如果複製改一改大概只要一個小時
打掉重構可能要一個禮拜 還不保證會不會有甚麼多出來的bug
想請教大家在類似的情況
都用哪些標準來決定甚麼時候應該重構
作者:
alog (A肉哥)
2018-11-12 02:26:00做事情是這樣 如果你覺得某些事你這樣做可以省到後面很多時間你可以做 但實際效果沒有符合預期/有機會搞砸/婊到別人/自己扛責/你沒有你想像中的專業有把握 你就不該隨便亂動已經跑的很穩定的東西還有不要用感覺來判斷專不專業 應該要仔細分析優缺點再來抓一個正確的作法
作者:
gs8613789 (Shang6029)
2018-11-12 08:25:00沒事做的時候
作者:
Masakiad (Masaki)
2018-11-12 08:36:00你的狀況應該是因為沒寫測試案例才會覺得重構容易有bug
作者: t64141 (榕樹) 2018-11-12 09:04:00
維護越來越痛苦的時候
寫久了都會有感覺哪邊是應該要事先提出來復用的部分，很不科學但是真的是很吃肌肉記憶抽象一點的說就是會自動分類可變動與不可變動的部分吧
作者: t64141 (榕樹) 2018-11-12 09:21:00
然後不要習慣複製貼上改一行，很可怕
作者:
Argos (Big doge is watching u)
2018-11-12 09:41:00看了上面一堆人排斥重構 就知道台灣軟體業只會繼續腐爛
作者:
MixBear (米克斯)
2018-11-12 09:41:00重構是持續進行的 比如你現在這時候遇到這狀況 就要拉正，而不是持續放任歪樓
作者:
Argos (Big doge is watching u)
2018-11-12 09:42:00重構這種事有時根本就舉手之勞而已 順手改一點改一點老實說 會不會想去重構 跟工程師自身的修養有很大的關係你夠不夠認真看待你的專業 就決定你對重構的態度回到現實面 你要重構當然要跟上級討論並且獲得許可及時間如果上面管理方都同意 你當然應該要開始重構但這件事應該是由工程師自己發現問題 並主動向上面提出
作者:
MixBear (米克斯)
2018-11-12 09:45:00最討厭維護複製貼上一堆相似程式，然後同樣邏輯要改漏東漏西的
作者:
Argos (Big doge is watching u)
2018-11-12 09:45:00如果上面死都不願給時程 那你還有藉口讓它放著爛沒關係
作者:
MixBear (米克斯)
2018-11-12 09:46:00造成後人不便，自己也常埋地雷的程式片段
作者:
Argos (Big doge is watching u)
2018-11-12 09:47:00而不是聽到要改Legacy就避之為恐不及
作者:
Argos (Big doge is watching u)
2018-11-12 09:48:00我講的是態度方面 至於執行細節 原本Legacy連測試都沒 怎麼改 嚴格來說都不算是重構就是了 XD
作者: ghmsxtwo (YI) 2018-11-12 09:49:00
離職前
作者:
alihue (wanda wanda)
2018-11-12 10:40:00一堆人排斥重構，然後又嫌台灣軟體業爛反正到最後也是牽拖到老闆，不檢討自己市面上很多重構的方法，包含寫完整的測試與ci/cd，確定你在可控的風險下重構。不重構只會讓後人東補西補，踩地雷讓台灣的軟體缺一個比一個還屎
重構沒那麼簡單 做得好沒人理 出錯被釘到死這是政治問題 不是軟體問題
作者:
cphe (魔鬼藏在垃圾筒裡)
2018-11-12 11:05:00打掉重練政治問題比較多，做久就知道為什麼，有時候不是你想做就有辦法執行除非上面決策的人打從心裡想這麼做
作者:
testPtt (測試)
2018-11-12 11:13:00重構最基本要有明確的spec
作者:
IDL (IDL)
2018-11-12 11:24:00想離職時
作者:
alihue (wanda wanda)
2018-11-12 11:36:00重構是一群小修改的集合...稍微抽出method或rename都算
https://martinfowler.com/books/refactoring.html雖然繁中譯本已經絕版，但簡體書大家也可以加減看一下作者就是定義重構的人Its essence is applying a series of smallbehavior-preserving transformations, each of which"too small to be worth doing".
我是會考慮重構對我是否Z>B 如果以後能省很多時間我就會重構 而不是以公司角度考量
作者:
Argos (Big doge is watching u)
2018-11-12 12:01:00政治的確才是真正的問題 但我上面在說的是工程師本身的態度一堆人就是寧可放在那邊爛也不想去動 甚至上面給你時間叫你改你都千推萬推找一堆藉口 這種就是垃圾 軟體界的毒瘤你想重構但上面不給你時間和資源那就算了阿 至少你提過了有想要重構的態度出來就行了 至少在這種心態下 你新產出的程式不會差到哪裡去 因為過去的垃圾你都看不順眼了但如果懶得去管過去垃圾 那非常有可能未來也是繼續出垃圾
作者:
a926 (Aaron)
2018-11-12 12:06:00重構很難？
作者:
alog (A肉哥)
2018-11-12 13:33:00沒有人排斥重構 是你本不該就隨便亂動已經final的code 這種都是團體內有共同共識考量到長期維護同案/持續上線營運的才會慢慢修改 你一人專案或完全你負責要怎樣改都是你的事只要是在合理的時間範圍完成你要自high/練功都行重構都是會發生在有必要做的時候 而有必要做的時機是在你真的有看到明確的問題時候你知道怎麼改比較正確 跟獲得更大效益不是你在那裡自high想改就在那裡下刀動手小弟做系統幫專案做重構改了數百組核心也寫了數百組測試不知道這個心得不知道夠不夠格上次一位只是改個function覺得沒問題也測過了上線直接當天飛起來 你以為沒壓力啊
作者:
alog (A肉哥)
2018-11-12 13:42:00我剛好朋友也有主力的產品 一個系統的營收是用千萬在計算 開個 Basecamp 看到滿滿記載要重構的地方 都是有原因跟理由的真的從來沒看過用感覺在做事 幹這件事的人已經飛上去了(上述那位）
作者:
iamshiao (CircleHsiao)
2018-11-12 18:12:00隨時
作者:
solonwu (絕對的信仰可以革新命運)
2018-11-12 22:39:00有把握不會出包的話我會重構
作者: windlll (我要工作阿) 2018-11-12 23:09:00
舊的不動，新的慢慢寫，然後拿之前的test跑三次確定沒問題後才拿出來
作者:
ppHomer (三腳貓)
2018-11-13 11:50:00重構有很多層次 只是約分/提出一個共用的func 也算重構將某變數或函式 rename成比較有意義看得懂的名稱也是重構將重覆出現的字串 改成const variable來使用也是重構雖然都是小小的整理 都算是重構, 也都需要進行測試
作者: vul3kuo (Glory) 2018-11-13 13:27:00
長官看你都準時下班的時候
作者:
bobju (枯藤老樹昏鴉)
2018-11-13 15:45:00既然你會猶豫,那就是想得不夠徹底,想到你決定要做(或不要),那就對了
作者:
tvbic 2018-11-13 19:43:00Never
作者:
loadingN (sarsaparilla)
2018-11-14 01:15:00吃飽太閒? 自己開個branch去玩啦
作者: lnmlee 2018-11-15 15:10:00
你想要長期領養這隻野貓的時候你就會想為他洗澡
作者: ak2840 (77529685) 2018-11-16 14:46:00
打掉就不是重構了 那是重練