Re: [討論] 重構之前要寫測試 不然不要重構
※ 引述《Ghamu (貓丸)》之銘言：
: 想想這應該算是一種迷思吧
: 理論上是這樣沒錯
: 但事實上之前都沒寫測試了
: 你怎麼證明他之前是對的呢?
: 所以我大多都直接給他改下去
: 反正重構後東西也比較清楚
: 即使有錯 也比起蝦雞巴狗爛毛程式碼好除錯
: 之前前輩都說會動的程式碼不要去碰
: 然後就一球在那邊
: 我說要改 他就說
: [啊你有寫測試嗎?]
: 開發時程又不允許
: 就一球在那邊越來越痛苦
: 會動的爛程式碼越來越多
: 不知道大家怎麼看
: -----
: Sent from JPTT on my Sony F5321.
人生在世，吃飯跟拉屎都是要做的，應該沒有人會說，
要先吃飯不然別拉屎，還是先拉屎不然別吃飯。
改扣就是改扣，框個名字自稱叫重構，
是不是不知道，但即使是重構，本質還是改扣。
測試是為了改扣順利，不寫測試還是可以改扣。
正如同拉屎跟吃飯有介於有跟沒有之間的相依性，
簡單的道理，裝模做樣之後就好像不簡單了。
-----
Sent from JPTT on my Google Pixel 3 XL.
--
網頁上拉近距離的幫手 實現 GMail豐富應用的功臣
數也數不清的友善使用者體驗 這就是ｊａｖａｓｃｒｉｐｔ
歡迎同好到 AJAX 板一同討論。
--
這樣也可以一篇
我覺得重構應該是開發時進行的，大大你怎麼想？
多數人做的重構與其說是重構，還不如說是重寫，包裝成重構不過是種自我安慰。
原來是改code 一直聽人講重構都聽不懂是啥
重構就不影響功能的改動啊
寫扣就是寫扣，框個名字自稱叫測試
是不是不知道，但即使是測試，本質還是寫扣
簡單的道理，裝模做樣之後就好像不簡單了
沒錯，孺子可教也
改扣分很多種，重構是其中一種，保有原有功能前提下
改寫或重寫程式碼追求更好的程式碼品值
與其說追求更好的程式碼品質，倒不如說與自己熟悉的 convention 更接近的寫法。
以前中學都會要求一道數學題目用多種解法
再從不同解法比較命題的用意
曾何幾時 改程式碼做一樣的事情這麼不堪了
重點是保有原來行為啊...
利用封裝 解構等技巧，補上測試固定程式碼的行為後，再開始
重構。
一般的寫扣幾乎就是憑著莫名的信心重寫，然後說這是重構XX
各種 code change (包括重構與其他) 最後真的沒改到行為的, 就我工作經驗裡面, 不到 5% . refactoring 通常是中間的一個過渡程序, 不是真正的目標. 但我們在談論這件事情卻老是把他當一個目的來講, 我覺得是莫名其妙的事情.
※ 編輯: TonyQ (210.61.209.201 臺灣), 07/07/2020 10:50:46不是前人的坑或者爆炸性需求要重寫，對老闆說要重寫
一定被打槍只好包裝起來叫重構嗎...
樓上這種需求的話, 我常用的說法叫做局部重寫, 這個說詞比
重構好用. 反正局部多大部是你說了算.
我自己看過比較多的用法, 其實是在幫需求抓多一點 buffer.
重構跟改扣還是有差別吧 就如同吃飯跟吃糙米飯 或者拉
屎跟拉稀之間的區別一樣吧
A 屬於 B ，要談 A 跟 B 的差別是要談什麼。子集跟父集只有元素的差別，沒有交集的差別啊。
※ 編輯: TonyQ (61.231.78.150 臺灣), 07/08/2020 05:26:3535
[討論] 重構跟kpi的考量假設以下情境 有個功能A、B都會用到相同邏輯，且有兩份重覆的code (沒有unit test保護，而且年久失修 要加入unit test會需要更多時程) 現在要加入C，也會用到相同邏輯 身為合格的工程師 應該會把ABC重覆的部份提取出來26
[請益] 這種情況要怎麼重構我現在遇到一個情況 同時跟其他人開發很相似的功能 舉例來說 我跟B同時開發兩個電商網站 一個叫博客來，一個叫蝦皮好了 B已經建好博客來商品列表頁面 我也要建立蝦皮的商品列表 想把B建的博客來頁面拿來用18
[心得]以策略模式重構switch case或if (影片)最近在客戶那邊一起 pair 重構 legacy code， 碰到了一大段 if/else statement，用來判斷什麼時候該使用哪一種cache， 並依照不同 cache 的邏輯來決定回傳的內容。 發現還是有蠻多風氣比較封閉的公司對這類型的基本功跟處理不是很熟悉， 可能是對 code smell 不熟，對重構不熟，對 design pattern 不熟，對工具不熟。![[心得]以策略模式重構switch case或if (影片)](https://img.youtube.com/vi/zO-NnNC-xyg/mqdefault.jpg "[心得]以策略模式重構switch case或if (影片)")
15
Re: [請益] 這種情況要怎麼重構我這篇寫的跟原原PO的狀況無關 ※ 引述《tbpfs ( )》之銘言： : 其實我真的不懂為什麼要急著重構 : 有好處嗎? : 一般而言，重構都是發生在農閒的時候7
[請益] 有關泰迪軟體-例外處理設計與重構實作班請問版上各位先進有人上過泰迪軟體-例外處理設計與重構實作班嗎？ 方便分享一下心得嗎？ 或是有同好想一起報名嗎？2個人一起報一個人可以省2000元喔，謝謝 --3
Re: [請益] 這種情況要怎麼重構其實我真的不懂為什麼要急著重構 有好處嗎? 一般而言，重構都是發生在農閒的時候 就是沒有新案子在趕，老闆又要想辦法把人力資源給排滿 以免被上面丟一坨賽過來的最好理由2
Re: [請益] 這種情況要怎麼重構如果專案有deadline的壓力建議是先各自發展以不相互影響為前提，最後再用剩餘時間開 一個分支做重構。其實這就是在規劃專案時沒有一個主要主導的設計人，沒有定義從系統 到功能的分工，導致代碼重工，而且缺乏溝通。 真的建議未來有機會在主導你還是要自己學會定義好工作，先學習不寫code就可以訂出功 能以及架構。我自己工作後常常遇到工程師很喜歡自幹，還沒開始就急著寫code，而不是2
Re: [請益] 重購退稅問題借用文章 請問是否有人能分享，舊制和新制在重構退稅的差別？ --
![Re: [請益] 這種情況要怎麼重構](https://yt3.ggpht.com/ytc/AMLnZu8OJyPPVMQ7ijoc9ewwrNysCZr1NWZr4Bwqeo5H_Fk=s900-c-k-c0x00ffffff-no-rj "Re: [請益] 這種情況要怎麼重構")
![[請益] 辦公室設備挑選](https://i.imgur.com/2Kz9qSkb.png "[請益] 辦公室設備挑選")