PTT推薦

Re: [請益] 這種情況要怎麼重構

看板Soft_Job標題Re: [請益] 這種情況要怎麼重構作者
EricTCartman
(阿ㄆㄧㄚˇ)
時間推噓15 推:15 噓:0 →:31

我這篇寫的跟原原PO的狀況無關

※ 引述《tbpfs ( http://pse.is/tbpfs )》之銘言:
: 其實我真的不懂為什麼要急著重構
: 有好處嗎?
: 一般而言,重構都是發生在農閒的時候

重構有好處, 而且有不得不做的狀況

我曾經遇到效能瓶頸,

發現是在整個流程順序上只要重新調整並安插幾個預處理的階段就能大幅提升效能

但原本的code就不是很clean, 隨便一個method破500行, 一個class有7、80個method

有二十多個boolean變數當作flag在控制狀態(但其實只要用3個變數就能搞定)

並且沒有unit test作保護


所以:

1. 花時間補unit test、再重構

2. 重寫

2當然最不實際, 1很多公司也不會認同, 所以最後就是直接做重構,

效能最後當然是有出來, 可讀性也提升很多



但老實講, 做的真的很痛苦

平時順手整理code那當然是舉手之勞

用千行來計的重構絕對不想再做一次, 重構完bug還算你頭上, 爽只有爽到別人而已



很多老鳥應該都知道了,這邊建議剛出社會的新鮮人:

就算你知道重構能夠大幅提升效能改善可讀性,
也要裝作不知道, 更不要主動提出重構
被你重構code的人可能會不爽你,
自己做了工作還變多 錢還是一樣,
爽只有爽到其他同事而已


公司大家寫哪種code就跟著寫哪種, 寫爛code搞得難維護更顯得你重要, 反正pm也不懂

--

※ PTT 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.231.112.12 (臺灣)
PTT 網址

leo591626706/25 10:32我個人很難對這種無可奈何妥協,所以我寧願改的很痛

leo591626706/25 10:32苦,我也不寫糞扣,反正大不了就開除我也沒差

ura121006/25 10:36大家好像很害怕重構 如果是以TDD開發的話 重構只是其中

就我所知國內不少公司是沒有在run tdd, 就算有, 稍有年紀的公司還是會有legacy code

ura121006/25 10:36一個步驟而已 如果重構沒有建立在單元測試上 那重構可能

ura121006/25 10:36會提早結束你的職業生涯

重構當然還是從簡單的整理開始做起, snippet內的邏輯是能夠確認的; 我覺得把單元測試與重構的成功與否畫上等號是有點詭異的

※ 編輯: EricTCartman (36.231.112.12 臺灣), 06/25/2020 10:47:11

Nitricacid06/25 11:07台灣應該是要重構就塊陶吧= = 單元測試只能保護你加

Nitricacid06/25 11:07功能的時候不要弄壞

ura121006/25 11:10依據Martin Fowler的定義「在不改變軟體外部行為的前提

ura121006/25 11:10下,改變其內部結構,使其更容易理解且易於修改 」,我

ura121006/25 11:10的認知是重構並不是效能優化而是增加可閱讀性,如果沒有

ura121006/25 11:10以單元測試案例為基礎,那麼重構就是在增加引入bug的機

ura121006/25 11:10

假設有10000行code, 流程會參考某個物件的狀態而變化, 今天重構其中100行, 在這100行內改變該物件的狀態, 補了測試也證明該單元沒有錯 但除此之外還有9900行, 實務上你也會把那9900行的測試補完才繼續重構嗎?

※ 編輯: EricTCartman (36.231.112.12 臺灣), 06/25/2020 11:22:56

TAKADO06/25 11:21原po的例子應該是他要先重構別人的code才有辦法加優化的功

TAKADO06/25 11:21能進去,這種就常常改也不是,不改也不是。但是”在台灣”

TAKADO06/25 11:21,要嘛重構就默默做完不要聲張,頂多就是簽入時留個到此一

TAKADO06/25 11:21遊註解深藏功與名,要嘛就是你位置足夠高,可以主導架構或

TAKADO06/25 11:21專案方向跟時程,不然很多時候都是自找麻煩。

vi00024606/25 11:36只能在開發相關功能時順手改 這樣才會測到比較保險

ura121006/25 11:45如果我要重構1萬行的程式 我還是會先寫單元測試 但如果

ura121006/25 11:45考慮時程壓力 這種技術債的東西誰接誰倒楣

Csongs06/25 12:03推先寫測試再重構,上線沒寫測試重構根本搞事

jack52906/25 12:05有測試重構才舒服啊,改完跑測試全過就舒坦,但寫測試才

jack52906/25 12:05是真正地獄XD

Csongs06/25 12:07另外接收別人的code重構 ,根本吃力不討好

kingofsdtw06/25 12:11雖然閉著眼睛良心上很痛苦...

kingofsdtw06/25 12:12但是也只能等產品整個周命期過..

MOONY13506/25 12:14我有看過拿著重構去跟公司要時間的人,通常都是.....

MOONY13506/25 12:15上面會說你想重構是你的事情 但時間到東西還是要出來

devilkool06/25 12:15個人滿喜歡加新功能時順便重構 還好本來就有unit test

seal011206/25 12:25重構如果不算考績, 然後還被靠腰說那是你自己平常就要維

seal011206/25 12:25護的 你就不會想重構了

comicat06/25 12:26但有些code一整包雜在一起,很難在重構前先有單元測試..

yamakazi06/25 12:26我們公司反而很鼓勵重構,因為產品已經發展成熟沒什麼事

yamakazi06/25 12:26做,只好常常重構來硬擠出一點事做

comicat06/25 12:27測試如果寫得比待測程式更複雜,也只會增加維護困難吧..

tvbic06/25 12:45這才是職場真實環境

t6414106/25 14:44增改需求時順便重構,這樣出 bug 比較好解釋,否則就只能

t6414106/25 14:44特別找出維護/效能上的改善點來說

Gaitz06/25 17:08這跟重構的定義不一樣吧 根本不是重構 已經是為了效能提升

Gaitz06/25 17:08做的新功能了

不是重構; 但沒重構很難做改善. 重構途中也有可能踢掉重複、冗餘的計算部分

Gaitz06/25 17:09這只說明你們公司在開發 feature 根本沒有做測試而已 XD

是針對10年前的code進行效能提升, 我不覺得提升效能算是做一個新feature legacy code沒做測試這是大家都知道的事

TonyQ06/25 18:10是說寫 test 也只能測到已知的問題, 我意見跟樓上一樣,

TonyQ06/25 18:10這是重新開發新功能了. XD

TonyQ06/25 18:11另外重構不會碰到一萬行還是一千行的問題,重構就是涵蓋問題

TonyQ06/25 18:11一萬行或一千行沒有差別, 做法都是一樣的.

做法一樣, 時間跟規模不會一樣, 這你認同吧

※ 編輯: EricTCartman (36.231.112.12 臺灣), 06/25/2020 21:01:02

viper970906/27 01:27推一樓