Re: [心得] 花了很多時間重構卻被打槍用舊code
既然有人發文了,那我也來閒聊閒聊
程式碼阿,就不斷地推陳出新
新架構淘汰舊架構,舊架構不重構也遲早因為各種理由被砍掉
前公司很有遠瞻性
他們終於發現.Netframework 4.0 這東西不行了(大約20年)
webform搭配jQuery,連一個打後端API的功能都沒有
我剛到的時候看到 PageLoad() 一臉黑人問號
然後也去了解,為啥我們客戶十幾萬,使用網站的比率不到2成
用那不到2成的功能
甚至很有心的實地訪談,出題目去找客戶使用,找找問題在哪裡
簡單說結論: 因為難用到不行啊
介面老舊,轉圈圈超久,功能分類奇差無比
還會從.cs 檔案傳字串回去前端組元件(懂得都懂)
然後就報錯
回來主題,所以他們花了三年的時間準備、規劃
找了廠商重新設計UI,請了新的前端工程師套用Angular前端頁面
搭配.Net Core 8 想要重新改革
改成微服務架構跟上雲端
這一切都是上面有心要改革想要做好的內容(畢竟花了三年)
上工做了半年以後
來了一個新長官
新來的長官覺得這太浪費時間了,『啪! 沒了!』
但是他還是想要有新的功能
所以最後他決定把Angular鑲嵌進去webForm裡面
就是某些新功能點進去,畫面是由Angular來做的
後端API改成中台架構那是另一個故事
最終結論
沒錯,要不要重構不是我們這些小工程師決定的
就算長官決定要做了,而且也已經開始做了
也是有可能新來的長官一來你就GG
畢竟大家都是出來混口飯吃的
真的不爽逃命比較實在
重構做好了沒有KPI,做壞了全部算你頭上
說來說去每間公司都是洞
就自己挑一個比較舒服的洞蹲著吧
--
整套翻新就儘量用 strangler fig pattern 吧
中台就是個傻逼架構
真正該解決的問題不去解 引入更多的複雜度以為可以解決
問題 實際上只是騙開發經費 早晚要整套打掉重做
我完全同意你說的 目前的這一大包,就是因為以前不願意升級架構 一堆程式碼跟開發流程為了將就這坨垃圾 導致後續開發維護上的一大困難 好不容易有人要出頭要做事情 又被收回去惹
新長官就敏捷啊 前任那套瀑布開發 三年規劃 半年開發
上線日不知道哪時候 你怎知道你做的是顧客要的 上線
後流量到縮怎辦?
升級架構本來就是要漸進式 慢慢把webform 邏輯抽成獨
立api 用現代框架疊新頁面 迭代交付才能控制風險
大破可能大立 但更多的是直接死給你看
當然啦敏捷對工程師通常不是啥好事 大家都想重寫 誰想
去改別人留的坑
半年開發是因為新的主管砍掉專案了,不是只開發半年就要上 原本的目標是要逐漸拆功能,跟舊的併行 慢慢引導客戶到新的網頁去 然後,這網站沒有量縮問題 因為本來就沒流量
同意樓上,
大家都想重寫,
只有少數人想看前人的code
這不是大家想重寫 是上面有心想重寫 就是那堆疊迭代的思維 不把問題根除,反正總是有更重要的事 造就了我上次的文章結果 老實告訴你,這公司大家只想養老退休 那一堆爛扣是給後來的人看的
這不叫敏捷喔 把 angular 鑲嵌到 webform,以後要改成正
常的spa有多少工要做XD 差不多又是重寫一整套的工作量
甚至超過 因為你要釐清在webform生命週期下的這些頁面
行為 確保你新的常規spa應用是否有相同的行為。不是你把a
ngular component 拿出來兜一兜就好了
我就不懂這維護到底要怎麼做 有問題到底要算在哪邊,要怎麼去抓問題 真的到時候要翻,還是要全翻
有賺錢就好 網站沒人用大家更輕鬆
就算新的網站上線 團隊開發的思維沒變一樣會搞爛
對啊有賺錢就好 反正公司不是靠你的網站賺錢的 你網站怎樣都沒差
當你東湊西湊 東西還是可以運行 無形間你的功力就大增
了 下次面試你就多了一堆東西可以講
你確定你要拿webform跟別人談嗎?
怎麼聽起來是金融業
這個我們有機會再談
這故事看一看覺得很熟悉,有機會說說中台架構的故事嗎
下次吧 我之後整理整理再來聊聊
結果都是人跟管理問題最大 企業IT 沒比較多都 呵呵
台灣style的敏捷開發基本上只是用來榨乾PG的工具
管理層自己都搞不定了 帶大家瞎忙最實在了XD
Hotfix跟需求我全都要 才是台灣敏捷的style
我覺得需求都只剩fix 然後搭配一些無關緊要的功能 例如法規之類的
CRM本來就不管客戶啦
網路銀行 有沒有都沒差,反正都能分行端處理
你是不是再說長榮航空的網路訂票系統 ?
每次看到那個aspx副檔名我就搖頭
內部系統用老舊framework就算了 但公開的網站需要高安全性
舊的框架有其安全侷限 security scan就一堆安全性問題
安全性問題 小聲說,這是另一個笑話了
那又怎樣? 你還不是乖乖用,而且有出問題嗎?
看你要出什麼樣的問題 說的也沒錯,沒人用就是沒人用 反正不用,就去分行叫分行用
換個工作
對啊,一個蘿蔔一個坑 找個自己喜歡的蹲
※ 編輯: TurtleGods (59.102.178.216 臺灣), 09/20/2025 16:30:3834
首Po最近案子快收尾在收斂bug 身為救援大隊長的老人我被指派到維護一個很老的API 老API的設計已經無法滿足擴充需求 新的擴充功能造成BUG 於是我花了大量時間甚至debug到天亮甚至請無薪假![[心得] 花了很多時間重構卻被打槍用舊code [心得] 花了很多時間重構卻被打槍用舊code](https://img.youtube.com/vi/HvLXaAle5jw/mqdefault.jpg)
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 印度仔會簡稱 KT1
喔 老屁股來說話了 話說把程式重構不是壞事 壞事是....重構的有對嗎? 有對應的回歸測試驗證你重構對嗎? 另外這些時間和風險,上面有人願意扛嗎?5
我隨便舉個最簡單的例子 二段式左轉跟圓環 為什麼大家都在罵, 但是要改掉也一堆人在罵? 因為大家都習慣了,雖然很智障,10
正確性,你是重構別人的code,意思是說,你有測完 【所有】的input 在【所有】的狀態下,的【所有】的output?? 當然要包括Exception。 至於可讀性+100%這種心理自high 的,真的無法講什麼,正如有人回應, 你寫的Code 放手一週後回頭看,相信你又要【重構】了。7
我來響應一下,要怎麼說服工程團隊領導重構 拿安全性壓他,資安這東西,大家都懂,但大家也都不專業 舊架構要嘛運行的環境有已知漏洞、要嘛依賴套件有已知漏洞 去 CVEdetails.com 查一下,整理一下已知漏洞高危清單 用魔法對付魔法,「不改的話有問題你要負責嗎?」
37
[請益] 想知道其他公司前端會被要求學後端嗎?我是後端工程師 工作到現在不知不覺已經2年了, 從第一份工作開始就開始要求串接前端並處理各種元件的開關, 但都沒遇到前端被要求來了解後端的架構, 是否如標題想問的,只會發生後端學前端,而沒有前端需要學後端的問題?20
Re: [討論] 前端比較痛苦還是後端本魯全端工程師 個人覺得後端比較痛苦,而且要會的不比前端少,可能還更多 因為所有的business model 都在後端,有些商業邏輯複雜到你會想死 前端所需要的功能,後端都要刻api出來(所有資料錯誤,80%都是後端吐的資料有誤) 而且前端的資料驗證,基本上後端為了安全性問題,全都要在再作一次16
Re: [請益] 這種情況要怎麼重構1. 你不應該去動別人開發中的 code, 除非 pair 或你是有被授權的人. 2. 你可以使用他的 code , 建 common, 但你不應該改回他的部分(理由1). 3. 假設改完會有衝突, 那表示你做的不是重構. 4. 如果完成再重構會花更多時間, 那表示你做的不是重構. 5. 你要用他的 code , 跟你要整理重構, 是兩回事.16
Re: [問卦] 「Cubo Ai 寶寶攝影機」真的不行了嗎?看到推文提到重構,我想說的是 在台灣,重構,本來就是做功德 你今天發現公司的軟體技術債多到靠盃, 人家花一天就能搞定的功能你們公司要花三天, 換句話說,公司浪費了接近七成的工程師薪水在技術債上。15
[討論] angular值得花時間下去學嗎?大家好 小弟最近在家進修 看了一下angular 本身已會angularjs 目前書看到264/801頁9
Re: [問卦] 五倍券官網源代碼簡體註釋忘了刪?大家不要這麼嚴格 台灣本來就沒什麼程式人才 中國在各方面都狂甩台灣10條街 (AI, 前端, 資料庫, App開發等等) 抄一點程式碼還好啦 但是"較專業的工程師"會 //註解一下出處 例如下面這個截圖 會註解來自 stackoverflow的哪個連結![Re: [問卦] 五倍券官網源代碼簡體註釋忘了刪? Re: [問卦] 五倍券官網源代碼簡體註釋忘了刪?](https://i.imgur.com/kmJ3L9fb.png)
6
Re: [請益] 專精前端(或後端)vs全端工程師之前剛好有一份工作是全端,我不知道是否會趨勢化,但全端不一定是一人包前後的案子 事實上那是一份不小的專案,前後端各有數人在開發,甚至客戶 App 也會來串機器 簡單介紹一下那個專案架構 我方開發 web 前端,機器上跑大量 C 的程式,需要把既有 command line 東西視覺化 為了達成雲端操作,所以需要有一個全端來設計 API + SDK4
Re: [閒聊] 弄個網站是不是很貴啊?小弟剛滿25歲的菜鳥工程師 不負責任隨便講講 看你需求 純靜態網頁不需要存取資料跟啥功能的 確實程式或許不難2
Re: [請益] 這種情況要怎麼重構如果專案有deadline的壓力建議是先各自發展以不相互影響為前提,最後再用剩餘時間開 一個分支做重構。其實這就是在規劃專案時沒有一個主要主導的設計人,沒有定義從系統 到功能的分工,導致代碼重工,而且缺乏溝通。 真的建議未來有機會在主導你還是要自己學會定義好工作,先學習不寫code就可以訂出功 能以及架構。我自己工作後常常遇到工程師很喜歡自幹,還沒開始就急著寫code,而不是