Re: [請益] 這種情況要怎麼重構
我這篇寫的跟原原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也不懂
--
我個人很難對這種無可奈何妥協,所以我寧願改的很痛
苦,我也不寫糞扣,反正大不了就開除我也沒差
大家好像很害怕重構 如果是以TDD開發的話 重構只是其中
就我所知國內不少公司是沒有在run tdd, 就算有, 稍有年紀的公司還是會有legacy code
一個步驟而已 如果重構沒有建立在單元測試上 那重構可能
會提早結束你的職業生涯
重構當然還是從簡單的整理開始做起, snippet內的邏輯是能夠確認的; 我覺得把單元測試與重構的成功與否畫上等號是有點詭異的
※ 編輯: EricTCartman (36.231.112.12 臺灣), 06/25/2020 10:47:11台灣應該是要重構就塊陶吧= = 單元測試只能保護你加
功能的時候不要弄壞
依據Martin Fowler的定義「在不改變軟體外部行為的前提
下,改變其內部結構,使其更容易理解且易於修改 」,我
的認知是重構並不是效能優化而是增加可閱讀性,如果沒有
以單元測試案例為基礎,那麼重構就是在增加引入bug的機
會
假設有10000行code, 流程會參考某個物件的狀態而變化, 今天重構其中100行, 在這100行內改變該物件的狀態, 補了測試也證明該單元沒有錯 但除此之外還有9900行, 實務上你也會把那9900行的測試補完才繼續重構嗎?
※ 編輯: EricTCartman (36.231.112.12 臺灣), 06/25/2020 11:22:56原po的例子應該是他要先重構別人的code才有辦法加優化的功
能進去,這種就常常改也不是,不改也不是。但是”在台灣”
,要嘛重構就默默做完不要聲張,頂多就是簽入時留個到此一
遊註解深藏功與名,要嘛就是你位置足夠高,可以主導架構或
專案方向跟時程,不然很多時候都是自找麻煩。
只能在開發相關功能時順手改 這樣才會測到比較保險
如果我要重構1萬行的程式 我還是會先寫單元測試 但如果
考慮時程壓力 這種技術債的東西誰接誰倒楣
推先寫測試再重構,上線沒寫測試重構根本搞事
有測試重構才舒服啊,改完跑測試全過就舒坦,但寫測試才
是真正地獄XD
另外接收別人的code重構 ,根本吃力不討好
雖然閉著眼睛良心上很痛苦...
但是也只能等產品整個周命期過..
我有看過拿著重構去跟公司要時間的人,通常都是.....
上面會說你想重構是你的事情 但時間到東西還是要出來
個人滿喜歡加新功能時順便重構 還好本來就有unit test
重構如果不算考績, 然後還被靠腰說那是你自己平常就要維
護的 你就不會想重構了
但有些code一整包雜在一起,很難在重構前先有單元測試..
我們公司反而很鼓勵重構,因為產品已經發展成熟沒什麼事
做,只好常常重構來硬擠出一點事做
測試如果寫得比待測程式更複雜,也只會增加維護困難吧..
這才是職場真實環境
增改需求時順便重構,這樣出 bug 比較好解釋,否則就只能
特別找出維護/效能上的改善點來說
這跟重構的定義不一樣吧 根本不是重構 已經是為了效能提升
做的新功能了
不是重構; 但沒重構很難做改善. 重構途中也有可能踢掉重複、冗餘的計算部分
這只說明你們公司在開發 feature 根本沒有做測試而已 XD
是針對10年前的code進行效能提升, 我不覺得提升效能算是做一個新feature legacy code沒做測試這是大家都知道的事
是說寫 test 也只能測到已知的問題, 我意見跟樓上一樣,
這是重新開發新功能了. XD
另外重構不會碰到一萬行還是一千行的問題,重構就是涵蓋問題
一萬行或一千行沒有差別, 做法都是一樣的.
做法一樣, 時間跟規模不會一樣, 這你認同吧
※ 編輯: EricTCartman (36.231.112.12 臺灣), 06/25/2020 21:01:02推一樓
3
其實我真的不懂為什麼要急著重構 有好處嗎? 一般而言,重構都是發生在農閒的時候 就是沒有新案子在趕,老闆又要想辦法把人力資源給排滿 以免被上面丟一坨賽過來的最好理由16
1. 你不應該去動別人開發中的 code, 除非 pair 或你是有被授權的人. 2. 你可以使用他的 code , 建 common, 但你不應該改回他的部分(理由1). 3. 假設改完會有衝突, 那表示你做的不是重構. 4. 如果完成再重構會花更多時間, 那表示你做的不是重構. 5. 你要用他的 code , 跟你要整理重構, 是兩回事.2
如果專案有deadline的壓力建議是先各自發展以不相互影響為前提,最後再用剩餘時間開 一個分支做重構。其實這就是在規劃專案時沒有一個主要主導的設計人,沒有定義從系統 到功能的分工,導致代碼重工,而且缺乏溝通。 真的建議未來有機會在主導你還是要自己學會定義好工作,先學習不寫code就可以訂出功 能以及架構。我自己工作後常常遇到工程師很喜歡自幹,還沒開始就急著寫code,而不是26
首Po我現在遇到一個情況 同時跟其他人開發很相似的功能 舉例來說 我跟B同時開發兩個電商網站 一個叫博客來,一個叫蝦皮好了 B已經建好博客來商品列表頁面 我也要建立蝦皮的商品列表 想把B建的博客來頁面拿來用
35
[討論] 重構跟kpi的考量假設以下情境 有個功能A、B都會用到相同邏輯,且有兩份重覆的code (沒有unit test保護,而且年久失修 要加入unit test會需要更多時程) 現在要加入C,也會用到相同邏輯 身為合格的工程師 應該會把ABC重覆的部份提取出來24
重構的幾個迷思覺得最近很多文章都有些不求甚解的問題,來寫點論述。 1. 重構不是什麼了不起的事情 2. 變更程式碼,重寫舊的程式碼成自己爽的樣子,不一定是重構。 3. 重構是一種相對安全的工具型開發方法論, 但仍然有不少風險跟誘惑。18
[心得]以策略模式重構switch case或if (影片)最近在客戶那邊一起 pair 重構 legacy code, 碰到了一大段 if/else statement,用來判斷什麼時候該使用哪一種cache, 並依照不同 cache 的邏輯來決定回傳的內容。 發現還是有蠻多風氣比較封閉的公司對這類型的基本功跟處理不是很熟悉, 可能是對 code smell 不熟,對重構不熟,對 design pattern 不熟,對工具不熟。13
Re: [討論] 重構跟kpi的考量感覺這個標題就是個假議題,你說不重構A、B因為Unit test來不及寫,那你新寫的C就不 用unit test了? 然後你又說三個code一模一樣,假設你幫C寫完unit test了,那你不就也把AB搞好了嗎? 再退一萬步來講,AB沒有unit test大家用的那麼爽你還硬要去動也只是吃飽太閒,不如 好好寫你C的unit test,寫完大家就用C就好啦3
Re: [心得]以策略模式重構switch case或if (影片)因為有朋友想要 Python 的版本, 簡單的 legacy code 也可以讓他們玩玩 team build 練練手, 所以我就順手整理了 Python 的版本了。 - GitHub Repo & commit history: - 用 PyCharm 重構的影片,YouTube:2
Re: [討論] 重構之前要寫測試 不然不要重構人生在世,吃飯跟拉屎都是要做的,應該沒有人會說, 要先吃飯不然別拉屎,還是先拉屎不然別吃飯。 改扣就是改扣,框個名字自稱叫重構, 是不是不知道,但即使是重構,本質還是改扣。 測試是為了改扣順利,不寫測試還是可以改扣。