[討論] 重構之前要寫測試 不然不要重構
想想這應該算是一種迷思吧
理論上是這樣沒錯
但事實上之前都沒寫測試了
你怎麼證明他之前是對的呢?
所以我大多都直接給他改下去
反正重構後東西也比較清楚
即使有錯 也比起蝦雞巴狗爛毛程式碼好除錯
之前前輩都說會動的程式碼不要去碰
然後就一球在那邊
我說要改 他就說
[啊你有寫測試嗎?]
開發時程又不允許
就一球在那邊越來越痛苦
會動的爛程式碼越來越多
不知道大家怎麼看
-----
Sent from JPTT on my Sony F5321.
--
如果是老程式碼可以把手測流程自動化成functional test
不用執著於一定要寫unit test
如此一來不須要100% coverage也能安心重構
證明他是對的這件事因為在正式環境運行一段時間了沒
有使用者反應問題,基本上就是證明他沒錯
你怎麼證明他之前寫的是對的?是不是連需求都不清楚
不是證明是對的。是要證明改前後的輸出是一樣的。
很多情況是函式A寫錯除二 B只好跟著錯乘二 補回來
這時候只重構A或是只重構B都不能把錯誤"改正"
因為無法確定是不是只有B會吃到A的結果。
全新的需求就可以跟使用者來回確認。重構跟開發全新
需求是兩件事,你沒辦法在跟使用者去確認,所以你只
能自己確認
好好寫不行嗎
好險你沒改到出包 哪天出包你就知道為啥前輩都放著
不管了 嘻嘻
公司現在就能賺錢,為什麼要另外花成本重構?
測試只是為了得出相同結果的手段,你的目的是想重構
而不是減少測試。
你要提出重構的效益說服pm、老闆,而不是前輩,老闆
覺得重構好就會做了。
覺得樓上說的非常中肯,各種教條要配合想要的結果跟手段
盲從跟隨便說教條是迷思,而不看自己的情況、背後的理由
都不太好
理性是要有測試再重構,但還是要考慮實務問題
理想 打錯字
去找RD lead決鬥阿 pm懂個小喔
你要拿你的績效賭誰管得著
抱著離職的決心就可以唷
估開發時間就是要把測試考慮進去啊
你如果在開發團隊中夠力,可以去做,不然最好先找下一家
有沒有想過你改了人家東西,原負責人拒絕維護誰會死
你可以接下他的工作嗎?
這行亂動不屬於自己的東西來配合自己想法,是大忌!
團隊若實行code review和ticket system 哪有不能改的程式
我待過工廠IT也待過agile開發 製造業IT很符合樓上的說法
他之前寫的程式還有在幫公司賺錢就是對的
這是在釣魚?
程式對不對跟spec上怎麼定義有關,怎麼會跟有沒有測試
有關?一開始的核心概念沒搞懂你才會問這樣的問題
說的很對,反正績效算你的,技術債上門時大概也升官
跳槽了
反正改壞了出包你負全責不要推託說原本的code很爛
那你愛怎麼改都可以
寫測試也要懂以前的邏輯脈絡,但會重構就是以前的程
式混雜一起
到最後大家都不想補技術債,只想亂寫,然後bugfix在
丟給菜鳥亂補
真的很少接到舒服的code
你考機想吃餅我沒意見啊
把這時間省下來 刷leetcode、練英文比較實在
工啥小啦幹
推文看下來覺得這些系統真的很堪憂阿
這老議題了...
工作不要出包最重要
改好 上面不覺得有功 改爛馬上變戰犯
怎麼證明之前的對不對 不就是寫測試去驗證嗎...
就是遇過有人說要重構 然後也重構了 結果一堆bug又不
修 然後只好等下一個人來重構loop?
樓上,所以才要先寫測試後才重構,然後重構目標跟debug
完全不同,怎麼回有bug結果又重構這種操作?
時程都不允許還重構0.0
其實寫測試可以讓重構更快
菜鳥 程式出包責任是你扛還是前輩扛 別人扛責你幹嘛管
很多東西是有歷史因素的 沒搞清楚就亂重構容易出事
重構者不繼續維護 然後接任者有起了重構的心 loop就出
現了
*又
現實中遇過因為架構上限制包含整個協議重構 結果重構
後的東西太多問題不能用 省下重構時間想個新產品來玩
說不定還比較好
要改可以 出錯你扛 本來就是這樣了啊
每次都要把什麼擔責任加進來討論,重點就算有授權這邊也
一堆人搞不懂怎麼重構
爛 code 是造成 delay 跟 online issue 的元兇
會動不就是對的? 不然還能叫會動嗎?
不是重構要寫測試,是有測試比較好重構,沒測試你重構完了
還不是要手動測好測滿?
測試之前也要先理解業務流吧,很多很奇特的你認為的狗屁
邏輯其實都是有歷史典故而且不得不做的,當特例變成客戶
常規,你要不要配合?那你看不懂自作聰明修了...保重
有些邏輯寫錯的改成對的是會出事的==
其實是本來就該測試了 不是等到重構才在想
你又怎麼知道你寫的是對的XD
先下手再說
改成你以為的正確可能會出事
後來看前輩的操作是,把需求摸透,甚至說服上面的需求範
圍後,在還沒被授意前就硬幹前幾段提初步成果再說。
反正頭洗下去結果好看,頂頭多會給你試,要縮成本也不高
那是你的前輩credit夠多可以燒,一般人先斬後奏的下場
都不是太好
推Masa大
我的操作跟E大前輩差不多,不過是先在本機做實驗樣品,覺
得可行再去說服上面後才會真的正式做/commit
或是趁著需求變更順便做效果也不錯
小範圍重構免強睜一隻眼閉一隻眼說肉眼可判斷不會出錯
大範圍重構還不寫測試是想?
可憐哪 還在重構
一池豬屎,好不容易經過時間的累積,終於表面乾掉不會臭,就
沒必要去攪動它了!
目前手上的程式連文件spec 都沒有 所以我隨便改沒差
上班沒空寫測試 下班寫啊 就這麼簡單
你終究要作測試驗證,何不一開始就寫測試
大家講的差不多了,測試就是幫助確認品質,而已經上線過
的系統某種程度就是就過驗證的;所以不要偏離原本的行為
是有價值的,就看這個價值對你來說有多少(系統多少人使
用、是不是完全不能出錯的系統)
直接改下去,萬一發現改不好不是進退兩難?
長官沒說改,就別動嘿
就算不說測試,你怎麼證明你寫的會比原來的好?你覺得你
寫的比較好debug那只是因為是自己寫的啊,你走人後別人也
會這麼認為嗎?顆顆
會啊,之後還請我做consultant
比較殘酷的是....說沒時間寫測試的,實際給了時間還是寫不
出來QQ
還沒有真的user勇敢改不要怕 有真的user就問問看pm
妳問題比較大 開發時程不夠兩件事 1.能力不足 2.看不清
等級在哪邊 還想要重構
嘻嘻 你確定你改完會比較好維護? 一堆越構越爛邏輯越複
雜的例子
你的實力沒被認同才會被這樣說,只能靠你自己証明
如果你很強,怎麼做都是可行的
要了解架構才能寫出好的,有意義的測項吧
沒有了解,你能確定你的測法是正確的嗎
因為你只是改成你認為正確的,事實上現在運作沒出大問題
也許你寫出來的只是對你來說 你比較好debug
因為是你寫的,所以你會知道問題在哪,但對別人來說不是
其實應該說清楚一點 本來程式一大球 好幾行 分崩離析 拆成
小分小分 即使有錯也比一整包天書好解決吧
啊人家就會動沒出錯 哪會比你沒寫測試重構出錯差?
爛code至少用能動說服大家它能用了 你連測試都不想寫
要怎麼說服別人重構會比較好?
原PO似乎弄錯測試程式的目的了? 測試是為了確保行為一致
輸出正確與否 不是測試程式應該著力的點
35
[討論] 重構跟kpi的考量假設以下情境 有個功能A、B都會用到相同邏輯,且有兩份重覆的code (沒有unit test保護,而且年久失修 要加入unit test會需要更多時程) 現在要加入C,也會用到相同邏輯 身為合格的工程師 應該會把ABC重覆的部份提取出來3
[情報] 『1800 神魔特別報告』神魔工程師阿力山情報來源網址: 大家好我是『神魔改革行動部』的神魔工程師阿力山大。歡迎大家觀看『1800 神魔特別 報告』。26
[請益] 這種情況要怎麼重構我現在遇到一個情況 同時跟其他人開發很相似的功能 舉例來說 我跟B同時開發兩個電商網站 一個叫博客來,一個叫蝦皮好了 B已經建好博客來商品列表頁面 我也要建立蝦皮的商品列表 想把B建的博客來頁面拿來用24
重構的幾個迷思覺得最近很多文章都有些不求甚解的問題,來寫點論述。 1. 重構不是什麼了不起的事情 2. 變更程式碼,重寫舊的程式碼成自己爽的樣子,不一定是重構。 3. 重構是一種相對安全的工具型開發方法論, 但仍然有不少風險跟誘惑。16
Re: [請益] 這種情況要怎麼重構1. 你不應該去動別人開發中的 code, 除非 pair 或你是有被授權的人. 2. 你可以使用他的 code , 建 common, 但你不應該改回他的部分(理由1). 3. 假設改完會有衝突, 那表示你做的不是重構. 4. 如果完成再重構會花更多時間, 那表示你做的不是重構. 5. 你要用他的 code , 跟你要整理重構, 是兩回事.15
Re: [請益] 這種情況要怎麼重構我這篇寫的跟原原PO的狀況無關 ※ 引述《tbpfs ( )》之銘言: : 其實我真的不懂為什麼要急著重構 : 有好處嗎? : 一般而言,重構都是發生在農閒的時候4
Re: [討論] 重構跟kpi的考量我覺得有個盲點就是 重複程式碼的邏輯 我的經驗是在需求還沒穩定前 一樣的程式碼複製到不同地方才是最佳解 你根本不知道什麼時候 某個地方要用的邏輯不同 一但要改寫的邏輯不通 你就會被共用的程式碼卡住2
Re: [請益] coding style差太多怎辦?重構取決於你對自己的程度有多自信 假設已經發現問題 也覺得自己有能力修改 試著跟主管溝通看看 說「在自己任務時程不耽誤的前提下 有路過看到程式碼就稍微整理一下」 若有得到主管或同事許可就下去改 沒把握自己可以改好的話 量力而為 先從小區塊開始改起