Re: [心得] 花了很多時間重構卻被打槍用舊code
喔 老屁股來說話了
話說把程式重構不是壞事
壞事是....重構的有對嗎？
有對應的回歸測試驗證你重構對嗎？
另外這些時間和風險，上面有人願意扛嗎？
只要有一個答案是否
基本上被罵是一定的
如果你改的部分
不是系統的核心
自己形成一個閉環
那還沒話說
萬一有什麼東西共用到
上線後就等著加班加到爆炸
所以才有很多老屁股會說
即使程式再爛
能在線上跑正確的，都是好程式
不要輕易的去改他
就醬
--
※ PTT留言評論
34
首Po最近案子快收尾在收斂bug 身為救援大隊長的老人我被指派到維護一個很老的API 老API的設計已經無法滿足擴充需求 新的擴充功能造成BUG 於是我花了大量時間甚至debug到天亮甚至請無薪假![[心得] 花了很多時間重構卻被打槍用舊code](https://img.youtube.com/vi/HvLXaAle5jw/mqdefault.jpg "[心得] 花了很多時間重構卻被打槍用舊code")
13
分享我遇過的鬼故事 某公司裡面有A team跟B team B team負責維護的是一個堪稱屎山等級的legacy code A team覺得B team維護的程式碼真他媽臭 隔了一個module都能聞到臭味 花費了半年多 去寫了一個跟功能99%像的程式碼 然後也有unit tests13
我的建議是: 1. 要幹嘛要先講 2. 要耗用的資源多少要先講 3. 要達成的目標是啥要先講 還技術債也要看怎麼還，該決定的人去決定，10
問題是， 第一，責任: 你的責任是對整個系統負責嗎? 還是只負責修好BUG ? 從文中，我看到的是後者。哪麼，你去【重構】做什麼?25
看到這篇原原PO在其他篇底下聲稱 「可讀性+100%」 忍不住來回一篇 軟體開發裡面有一件很重要的事情是知識轉移 又稱 knowledge transfer 印度仔會簡稱 KT5
我隨便舉個最簡單的例子 二段式左轉跟圓環 為什麼大家都在罵， 但是要改掉也一堆人在罵? 因為大家都習慣了，雖然很智障，10
正確性，你是重構別人的code，意思是說，你有測完 【所有】的input 在【所有】的狀態下，的【所有】的output?? 當然要包括Exception。 至於可讀性+100%這種心理自high 的，真的無法講什麼，正如有人回應， 你寫的Code 放手一週後回頭看，相信你又要【重構】了。11
既然有人發文了，那我也來閒聊閒聊 程式碼阿，就不斷地推陳出新 新架構淘汰舊架構，舊架構不重構也遲早因為各種理由被砍掉 前公司很有遠瞻性 他們終於發現.Netframework 4.0 這東西不行了(大約20年)7
我來響應一下，要怎麼說服工程團隊領導重構 拿安全性壓他，資安這東西，大家都懂，但大家也都不專業 舊架構要嘛運行的環境有已知漏洞、要嘛依賴套件有已知漏洞 去 CVEdetails.com 查一下，整理一下已知漏洞高危清單 用魔法對付魔法，「不改的話有問題你要負責嗎？」
![Re: [心得] 花了很多時間重構卻被打槍用舊code](https://avatars.githubusercontent.com/u/8318854?v=4?s=400 "Re: [心得] 花了很多時間重構卻被打槍用舊code")
35
[討論] 重構跟kpi的考量假設以下情境 有個功能A、B都會用到相同邏輯，且有兩份重覆的code (沒有unit test保護，而且年久失修 要加入unit test會需要更多時程) 現在要加入C，也會用到相同邏輯 身為合格的工程師 應該會把ABC重覆的部份提取出來32
[討論] 寫程式的追求？寫程式不知不覺也一年半了 看著公司龐大的老舊程式 前人寫的實在雜亂 造成了維護上有一定難度 最近有心想要嘗試從簡單的地方開始試著重構26
[請益] 這種情況要怎麼重構我現在遇到一個情況 同時跟其他人開發很相似的功能 舉例來說 我跟B同時開發兩個電商網站 一個叫博客來，一個叫蝦皮好了 B已經建好博客來商品列表頁面 我也要建立蝦皮的商品列表 想把B建的博客來頁面拿來用24
重構的幾個迷思覺得最近很多文章都有些不求甚解的問題，來寫點論述。 1. 重構不是什麼了不起的事情 2. 變更程式碼，重寫舊的程式碼成自己爽的樣子，不一定是重構。 3. 重構是一種相對安全的工具型開發方法論， 但仍然有不少風險跟誘惑。17
Re: [討論] 重構之前要寫測試 不然不要重構這就是TAD, 一般做法是假設以前人做的是對的 拿以前的output當測資 避免以後的output跟預期結果不同 技術面的錯誤→沒有防呆/沒有釋放資源/overflow/沒有check 這應該不在討論範圍內, 也有客觀標準 行為與邏輯的部分才是有爭議的, 要嘛根本沒規格只有口傳16
Re: [請益] 這種情況要怎麼重構1. 你不應該去動別人開發中的 code, 除非 pair 或你是有被授權的人. 2. 你可以使用他的 code , 建 common, 但你不應該改回他的部分(理由1). 3. 假設改完會有衝突, 那表示你做的不是重構. 4. 如果完成再重構會花更多時間, 那表示你做的不是重構. 5. 你要用他的 code , 跟你要整理重構, 是兩回事.