Re: [心得] 花了很多時間重構卻被打槍用舊code
※ 引述《kingofsdtw (塔綠班)》之銘言:
: 最近案子快收尾在收斂bug
: 身為救援大隊長的老人我被指派到維護一個很老的API
: 老API的設計已經無法滿足擴充需求
: 新的擴充功能造成BUG
: 於是我花了大量時間甚至debug到天亮甚至請無薪假
: 新的API經過我反覆測試各種case都完美無缺
: 但是code review卻被質疑:
: 1. 是不是沒找到root cause
: 2. 幹嘛改動如此大? 只不過新加一點點功能幹嘛改架構?
: 心中五味雜陳...
: 好歹我也是coding master,我說該重構了就是該開始還技術債了
: 更上頭還是希望用最鴕鳥的方法繼續用舊架構一堆workaound當作root cause
: 是該離職了嗎? QwQ
問題是,
第一,責任:
你的責任是對整個系統負責嗎?
還是只負責修好BUG ?
從文中,我看到的是後者。哪麼,你去【重構】做什麼?
顯示自己很強?
為什麼有責任,因為每個人都要為自己做的事負責,既然責任不在你,你就負不了責。
第二: 正確性:
你確定你將所有input 都測一遍? 所有output 都測出來了?
不然,哪來的自信【完美無缺】。
一個軟體系統,最重要的第一點是:正確性,第二點是: 穏定 第三點是:效能。
你能保證哪一個?
系統要是出事,你又不是責任人,也保證不了,被打槍不就很正常?
你如果沒有責任的概念,哪麼你真的該離職了,不要害人害己。
自己去開發一套系統,天天去【重構】昨天的code。
--
open source projects:
https://github.com/terrylao/
--
正確性,未大量上機無法確定穩定,效能未知
但是code可讀性+100%
「可讀性+100%」這個不好說喔XD
可讀性+100%是對自己的可讀性嗎
確實
到頭來你也只敢保證可讀性啊…
可讀性+100% XDDDDDD
可讀性100% 跟穩穩賺100%的錢 很難選嗎
為了可讀性的重構 可以保證上線100%炸到天上去
可讀性+100%…..
可讀 +100% 笑了
clean code
可讀性+100%...... 靠!好猛..... 我是說笑點
100% 可讀...難怪 code review 會被質疑
34
首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. 要達成的目標是啥要先講 還技術債也要看怎麼還,該決定的人去決定,25
看到這篇原原PO在其他篇底下聲稱 「可讀性+100%」 忍不住來回一篇 軟體開發裡面有一件很重要的事情是知識轉移 又稱 knowledge transfer 印度仔會簡稱 KT1
喔 老屁股來說話了 話說把程式重構不是壞事 壞事是....重構的有對嗎? 有對應的回歸測試驗證你重構對嗎? 另外這些時間和風險,上面有人願意扛嗎?5
我隨便舉個最簡單的例子 二段式左轉跟圓環 為什麼大家都在罵, 但是要改掉也一堆人在罵? 因為大家都習慣了,雖然很智障,10
正確性,你是重構別人的code,意思是說,你有測完 【所有】的input 在【所有】的狀態下,的【所有】的output?? 當然要包括Exception。 至於可讀性+100%這種心理自high 的,真的無法講什麼,正如有人回應, 你寫的Code 放手一週後回頭看,相信你又要【重構】了。11
既然有人發文了,那我也來閒聊閒聊 程式碼阿,就不斷地推陳出新 新架構淘汰舊架構,舊架構不重構也遲早因為各種理由被砍掉 前公司很有遠瞻性 他們終於發現.Netframework 4.0 這東西不行了(大約20年)7
我來響應一下,要怎麼說服工程團隊領導重構 拿安全性壓他,資安這東西,大家都懂,但大家也都不專業 舊架構要嘛運行的環境有已知漏洞、要嘛依賴套件有已知漏洞 去 CVEdetails.com 查一下,整理一下已知漏洞高危清單 用魔法對付魔法,「不改的話有問題你要負責嗎?」
46
[討論] 系統越開發越多,負責的東西越來越多在公司待了好幾年,開發的系統越來越多。每個開發時都要搞懂一些新的業務邏輯,上線後 還要後續維護,有問題還要幫忙解決。 但我常常在想,人力沒變,但我身上的loading卻越來越重,現在的我比三年前的我多負責 了一堆系統問題,這樣是合理的嗎? 大家的公司都是這樣的嗎?21
Re: [討論] 系統越開發越多,負責的東西越來越多(恕刪) : 問題是身為資深成員的你,可否提出數據說明工程宅們整天在吵的code quality到底跟業 : 務的關係在哪 : 是不是做同樣規模的feature要花的時間越來越多 : 是不是release後常常出問題要修17
Re: [討論] 重構之前要寫測試 不然不要重構這就是TAD, 一般做法是假設以前人做的是對的 拿以前的output當測資 避免以後的output跟預期結果不同 技術面的錯誤→沒有防呆/沒有釋放資源/overflow/沒有check 這應該不在討論範圍內, 也有客觀標準 行為與邏輯的部分才是有爭議的, 要嘛根本沒規格只有口傳16
Re: [請益] 這種情況要怎麼重構1. 你不應該去動別人開發中的 code, 除非 pair 或你是有被授權的人. 2. 你可以使用他的 code , 建 common, 但你不應該改回他的部分(理由1). 3. 假設改完會有衝突, 那表示你做的不是重構. 4. 如果完成再重構會花更多時間, 那表示你做的不是重構. 5. 你要用他的 code , 跟你要整理重構, 是兩回事.15
Re: [請益] 這種情況要怎麼重構我這篇寫的跟原原PO的狀況無關 ※ 引述《tbpfs ( )》之銘言: : 其實我真的不懂為什麼要急著重構 : 有好處嗎? : 一般而言,重構都是發生在農閒的時候7
Re: [請益] 該辭職嗎?到哪都會遇到垃圾系統 還沒聽過哪家公司沒有垃圾code, legacy code, 歷史包袱的... 如果你的主要考量是這個系統太爛不想改他 那我會建議不要離職. 因為不管你走到哪,都會遇到一樣的問題2
Re: [請益] 這種情況要怎麼重構如果專案有deadline的壓力建議是先各自發展以不相互影響為前提,最後再用剩餘時間開 一個分支做重構。其實這就是在規劃專案時沒有一個主要主導的設計人,沒有定義從系統 到功能的分工,導致代碼重工,而且缺乏溝通。 真的建議未來有機會在主導你還是要自己學會定義好工作,先學習不寫code就可以訂出功 能以及架構。我自己工作後常常遇到工程師很喜歡自幹,還沒開始就急著寫code,而不是
![[請益] 中年求職困境 [請益] 中年求職困境](https://i.ibb.co/230tZgNr/sssss.jpg)