PTT推薦

[討論] 重構之前要寫測試 不然不要重構

看板Soft_Job標題[討論] 重構之前要寫測試 不然不要重構作者
Ghamu
(貓丸)
時間推噓26 推:35 噓:9 →:90

想想這應該算是一種迷思吧

理論上是這樣沒錯

但事實上之前都沒寫測試了

你怎麼證明他之前是對的呢?

所以我大多都直接給他改下去

反正重構後東西也比較清楚

即使有錯 也比起蝦雞巴狗爛毛程式碼好除錯

之前前輩都說會動的程式碼不要去碰

然後就一球在那邊

我說要改 他就說

[啊你有寫測試嗎?]

開發時程又不允許

就一球在那邊越來越痛苦

會動的爛程式碼越來越多

不知道大家怎麼看

-----
Sent from JPTT on my Sony F5321.

--

※ PTT留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 101.15.130.230 (臺灣)
PTT 網址
※ 編輯: Ghamu (101.15.130.230 臺灣), 07/02/2020 02:52:31

ousapas07/02 04:01如果是老程式碼可以把手測流程自動化成functional test

ousapas07/02 04:01不用執著於一定要寫unit test

ousapas07/02 04:02如此一來不須要100% coverage也能安心重構

keyboard5607/02 07:25證明他是對的這件事因為在正式環境運行一段時間了沒

keyboard5607/02 07:25有使用者反應問題,基本上就是證明他沒錯

chchang082007/02 07:26你怎麼證明他之前寫的是對的?是不是連需求都不清楚

NDark07/02 07:29不是證明是對的。是要證明改前後的輸出是一樣的。

NDark07/02 07:30很多情況是函式A寫錯除二 B只好跟著錯乘二 補回來

NDark07/02 07:31這時候只重構A或是只重構B都不能把錯誤"改正"

NDark07/02 07:31因為無法確定是不是只有B會吃到A的結果。

keyboard5607/02 07:32全新的需求就可以跟使用者來回確認。重構跟開發全新

keyboard5607/02 07:32需求是兩件事,你沒辦法在跟使用者去確認,所以你只

keyboard5607/02 07:32能自己確認

alihue07/02 07:53好好寫不行嗎

GinginDenSha07/02 08:04好險你沒改到出包 哪天出包你就知道為啥前輩都放著

GinginDenSha07/02 08:04不管了 嘻嘻

shingatter07/02 08:11公司現在就能賺錢,為什麼要另外花成本重構?

shingatter07/02 08:11測試只是為了得出相同結果的手段,你的目的是想重構

shingatter07/02 08:11而不是減少測試。

shingatter07/02 08:11你要提出重構的效益說服pm、老闆,而不是前輩,老闆

shingatter07/02 08:11覺得重構好就會做了。

yyhsiu07/02 08:12覺得樓上說的非常中肯,各種教條要配合想要的結果跟手段

yyhsiu07/02 08:13盲從跟隨便說教條是迷思,而不看自己的情況、背後的理由

yyhsiu07/02 08:13都不太好

hidog07/02 08:18理性是要有測試再重構,但還是要考慮實務問題

hidog07/02 08:19理想 打錯字

x00003200107/02 08:28去找RD lead決鬥阿 pm懂個小喔

Murasaki011007/02 08:50你要拿你的績效賭誰管得著

vi00024607/02 09:12抱著離職的決心就可以唷

Csongs07/02 09:14估開發時間就是要把測試考慮進去啊

allenxxx07/02 09:31你如果在開發團隊中夠力,可以去做,不然最好先找下一家

allenxxx07/02 09:32有沒有想過你改了人家東西,原負責人拒絕維護誰會死

allenxxx07/02 09:32你可以接下他的工作嗎?

allenxxx07/02 09:34這行亂動不屬於自己的東西來配合自己想法,是大忌!

umum2907/02 09:38團隊若實行code review和ticket system 哪有不能改的程式

umum2907/02 09:39我待過工廠IT也待過agile開發 製造業IT很符合樓上的說法

DCTmaybe07/02 10:34他之前寫的程式還有在幫公司賺錢就是對的

a92607/02 10:36這是在釣魚?

Masakiad07/02 11:10程式對不對跟spec上怎麼定義有關,怎麼會跟有沒有測試

Masakiad07/02 11:10有關?一開始的核心概念沒搞懂你才會問這樣的問題

strike556607/02 12:09說的很對,反正績效算你的,技術債上門時大概也升官

strike556607/02 12:09跳槽了

brucetu07/02 12:39反正改壞了出包你負全責不要推託說原本的code很爛

brucetu07/02 12:39那你愛怎麼改都可以

leo591626707/02 12:50寫測試也要懂以前的邏輯脈絡,但會重構就是以前的程

leo591626707/02 12:50式混雜一起

leo591626707/02 12:51到最後大家都不想補技術債,只想亂寫,然後bugfix在

leo591626707/02 12:51丟給菜鳥亂補

Csongs07/02 12:52真的很少接到舒服的code

sniper282407/02 12:59你考機想吃餅我沒意見啊

king2264907/02 13:08把這時間省下來 刷leetcode、練英文比較實在

deray07/02 13:36工啥小啦幹

Masakiad07/02 13:56推文看下來覺得這些系統真的很堪憂阿

cphe07/02 14:00這老議題了...

NTULioner07/02 14:20工作不要出包最重要

NTULioner07/02 14:21改好 上面不覺得有功 改爛馬上變戰犯

annheilong07/02 14:23怎麼證明之前的對不對 不就是寫測試去驗證嗎...

shooter55507/02 14:33就是遇過有人說要重構 然後也重構了 結果一堆bug又不

shooter55507/02 14:33修 然後只好等下一個人來重構loop?

Masakiad07/02 15:01樓上,所以才要先寫測試後才重構,然後重構目標跟debug

Masakiad07/02 15:01完全不同,怎麼回有bug結果又重構這種操作?

as2304124807/02 15:04時程都不允許還重構0.0

alihue07/02 15:24其實寫測試可以讓重構更快

luke7207/02 15:31菜鳥 程式出包責任是你扛還是前輩扛 別人扛責你幹嘛管

luke7207/02 15:32很多東西是有歷史因素的 沒搞清楚就亂重構容易出事

shooter55507/02 15:34重構者不繼續維護 然後接任者有起了重構的心 loop就出

shooter55507/02 15:35現了

shooter55507/02 15:35 *又

shooter55507/02 15:37現實中遇過因為架構上限制包含整個協議重構 結果重構

shooter55507/02 15:40後的東西太多問題不能用 省下重構時間想個新產品來玩

shooter55507/02 15:40說不定還比較好

Darkword198707/02 16:31要改可以 出錯你扛 本來就是這樣了啊

Masakiad07/02 16:55每次都要把什麼擔責任加進來討論,重點就算有授權這邊也

Masakiad07/02 16:55一堆人搞不懂怎麼重構

sharku07/02 17:10爛 code 是造成 delay 跟 online issue 的元兇

ssccg07/02 17:22會動不就是對的? 不然還能叫會動嗎?

ssccg07/02 17:25不是重構要寫測試,是有測試比較好重構,沒測試你重構完了

ssccg07/02 17:26還不是要手動測好測滿?

allenxxx07/02 17:44測試之前也要先理解業務流吧,很多很奇特的你認為的狗屁

allenxxx07/02 17:45邏輯其實都是有歷史典故而且不得不做的,當特例變成客戶

allenxxx07/02 17:46常規,你要不要配合?那你看不懂自作聰明修了...保重

bheegrl07/02 17:48有些邏輯寫錯的改成對的是會出事的==

vencil07/02 18:18其實是本來就該測試了 不是等到重構才在想

mpjp07/02 18:30你又怎麼知道你寫的是對的XD

hichcock07/02 18:47先下手再說

xephon07/02 19:12改成你以為的正確可能會出事

Ekmund07/02 19:48後來看前輩的操作是,把需求摸透,甚至說服上面的需求範

Ekmund07/02 19:48圍後,在還沒被授意前就硬幹前幾段提初步成果再說。

Ekmund07/02 19:50反正頭洗下去結果好看,頂頭多會給你試,要縮成本也不高

foreverk07/02 19:52那是你的前輩credit夠多可以燒,一般人先斬後奏的下場

foreverk07/02 19:52都不是太好

devilkool07/02 21:03推Masa大

t6414107/02 21:03我的操作跟E大前輩差不多,不過是先在本機做實驗樣品,覺

t6414107/02 21:03得可行再去說服上面後才會真的正式做/commit

t6414107/02 21:11或是趁著需求變更順便做效果也不錯

GoodFriday07/02 22:50小範圍重構免強睜一隻眼閉一隻眼說肉眼可判斷不會出錯

GoodFriday07/02 22:51大範圍重構還不寫測試是想?

clamperni07/02 22:54可憐哪 還在重構

v7q407/02 23:08一池豬屎,好不容易經過時間的累積,終於表面乾掉不會臭,就

v7q407/02 23:08沒必要去攪動它了!

Ghamu07/02 23:49目前手上的程式連文件spec 都沒有 所以我隨便改沒差

Nonegrame07/03 00:24上班沒空寫測試 下班寫啊 就這麼簡單

jasonwung07/03 00:32你終究要作測試驗證,何不一開始就寫測試

siriusu07/03 08:15大家講的差不多了,測試就是幫助確認品質,而已經上線過

siriusu07/03 08:15的系統某種程度就是就過驗證的;所以不要偏離原本的行為

siriusu07/03 08:15是有價值的,就看這個價值對你來說有多少(系統多少人使

siriusu07/03 08:15用、是不是完全不能出錯的系統)

bnd032707/03 10:27直接改下去,萬一發現改不好不是進退兩難?

InvincibleK07/03 15:06長官沒說改,就別動嘿

meowyih07/03 20:51就算不說測試,你怎麼證明你寫的會比原來的好?你覺得你

meowyih07/03 20:51寫的比較好debug那只是因為是自己寫的啊,你走人後別人也

meowyih07/03 20:51會這麼認為嗎?顆顆

Masakiad07/03 21:36會啊,之後還請我做consultant

APTON07/04 10:47比較殘酷的是....說沒時間寫測試的,實際給了時間還是寫不

APTON07/04 10:47出來QQ

play192107/04 11:19還沒有真的user勇敢改不要怕 有真的user就問問看pm

daddy2907/04 11:42妳問題比較大 開發時程不夠兩件事 1.能力不足 2.看不清

daddy2907/04 11:42等級在哪邊 還想要重構

lukelove07/04 12:03嘻嘻 你確定你改完會比較好維護? 一堆越構越爛邏輯越複

lukelove07/04 12:03雜的例子

stupid031907/04 16:23你的實力沒被認同才會被這樣說,只能靠你自己証明

stupid031907/04 16:24如果你很強,怎麼做都是可行的

panbanana07/04 17:22要了解架構才能寫出好的,有意義的測項吧

panbanana07/04 17:23沒有了解,你能確定你的測法是正確的嗎

mathrew07/05 12:18因為你只是改成你認為正確的,事實上現在運作沒出大問題

mathrew07/05 12:20也許你寫出來的只是對你來說 你比較好debug

mathrew07/05 12:20因為是你寫的,所以你會知道問題在哪,但對別人來說不是

Ghamu07/06 01:27其實應該說清楚一點 本來程式一大球 好幾行 分崩離析 拆成

Ghamu07/06 01:27小分小分 即使有錯也比一整包天書好解決吧

highwayshih07/06 07:25啊人家就會動沒出錯 哪會比你沒寫測試重構出錯差?

highwayshih07/06 07:29爛code至少用能動說服大家它能用了 你連測試都不想寫

highwayshih07/06 07:29要怎麼說服別人重構會比較好?

rodion07/06 17:20原PO似乎弄錯測試程式的目的了? 測試是為了確保行為一致

rodion07/06 17:21輸出正確與否 不是測試程式應該著力的點