Re: [心得] 花了很多時間重構卻被打槍用舊code
※ 引述《LeonH (Leon)》之銘言:
: 我來響應一下,要怎麼說服工程團隊領導重構
: 拿安全性壓他,資安這東西,大家都懂,但大家也都不專業
: 舊架構要嘛運行的環境有已知漏洞、要嘛依賴套件有已知漏洞
: 去 CVEdetails.com 查一下,整理一下已知漏洞高危清單
: 用魔法對付魔法,「不改的話有問題你要負責嗎?」
: 保證沒人敢挺身說我負責,就這樣,改善軟體供應鏈的同時,順便重構。
: 如果有人敢挺身而出,那恭喜,以後背鍋俠就是他了。
有個滿有趣的案例
OpenSSH 2006年有個CVE-2006-5051
是因為SIGALRM不當 導致heap管理的執行續被中斷
後來被修正 但在2021的時候又被錯改回來 叫CVE-2024-6387
OpenSSH 8.5p1 的release notes說明中為:
This release is focused on new features and internal refactoring.
https://bugzilla.redhat.com/show_bug.cgi?id=2294604
Marco Benatto提到
This regression was introduced in October 2020 (OpenSSH 8.5p1) by commit
752250c ("revised log infrastructure for OpenSSH"), which accidentally
removed an "#ifdef DO_LOG_SAFE_IN_SIGHAND" from sigdie(), a function that is
directly called by sshd's SIGALRM handler.
https://github.com/openssh/openssh-portable/commit/752250c
看來這哥們確實是在重構 因為原本sigdie變成sshsigdie
至於為什麼他要刪除#ifdef DO_LOG_SAFE_IN_SIGHAND
可能他覺得本來就很safe 也有可能他覺得行為一致
反正也沒有前人留下充滿怨念的註解警告
(反正大家一定見過那種"祖宗之法不可變"的程式碼註解警告
就跟進飯店房間要先敲門一樣 寧可信其有不可信其無)
所以他可能就直接刪除了
所以說以資安避免CVE出現的觀點來進行重構提議
老實講 我的想法是 嗯~~~
--
有趣案例推
推祖宗之法不可變
"祖宗之法不可變" XD
沒什麼不能變的 以前說路徑或檔名不能中文不能空格我照用
沒寫測試吧
施作的人 沒非常清楚規格 這樣寫測試也會寫不完整
若是修改的地方沒有長期被需要變更 那麼測試就成本沉沒了
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. 要達成的目標是啥要先講 還技術債也要看怎麼還,該決定的人去決定,10
問題是, 第一,責任: 你的責任是對整個系統負責嗎? 還是只負責修好BUG ? 從文中,我看到的是後者。哪麼,你去【重構】做什麼?25
看到這篇原原PO在其他篇底下聲稱 「可讀性+100%」 忍不住來回一篇 軟體開發裡面有一件很重要的事情是知識轉移 又稱 knowledge transfer 印度仔會簡稱 KT1
喔 老屁股來說話了 話說把程式重構不是壞事 壞事是....重構的有對嗎? 有對應的回歸測試驗證你重構對嗎? 另外這些時間和風險,上面有人願意扛嗎?5
我隨便舉個最簡單的例子 二段式左轉跟圓環 為什麼大家都在罵, 但是要改掉也一堆人在罵? 因為大家都習慣了,雖然很智障,10
正確性,你是重構別人的code,意思是說,你有測完 【所有】的input 在【所有】的狀態下,的【所有】的output?? 當然要包括Exception。 至於可讀性+100%這種心理自high 的,真的無法講什麼,正如有人回應, 你寫的Code 放手一週後回頭看,相信你又要【重構】了。11
既然有人發文了,那我也來閒聊閒聊 程式碼阿,就不斷地推陳出新 新架構淘汰舊架構,舊架構不重構也遲早因為各種理由被砍掉 前公司很有遠瞻性 他們終於發現.Netframework 4.0 這東西不行了(大約20年)
35
[討論] 重構跟kpi的考量假設以下情境 有個功能A、B都會用到相同邏輯,且有兩份重覆的code (沒有unit test保護,而且年久失修 要加入unit test會需要更多時程) 現在要加入C,也會用到相同邏輯 身為合格的工程師 應該會把ABC重覆的部份提取出來29
Re: [心得] 好的註解是解釋為何需要這段 code上週在重構某段程式碼時,其中一位同事在 code review 中建議把某個註解刪掉,另一 個同事看到這個評論時,在下面留了言說他認為不應該刪掉,於是我們就拉了一個小討論 ,聊在程式碼中寫註解這件事。 因為這個經驗,我回去重翻史丹佛電腦科學教授 John Ousterhout 寫的《A Philosophy of Software Design》一書,並整理了筆記。該教授的觀點是認為程式碼寫註解有很多好![Re: [心得] 好的註解是解釋為何需要這段 code Re: [心得] 好的註解是解釋為何需要這段 code](https://www.explainthis.io/static/images/twitter-card.png)
24
重構的幾個迷思覺得最近很多文章都有些不求甚解的問題,來寫點論述。 1. 重構不是什麼了不起的事情 2. 變更程式碼,重寫舊的程式碼成自己爽的樣子,不一定是重構。 3. 重構是一種相對安全的工具型開發方法論, 但仍然有不少風險跟誘惑。18
[心得]以策略模式重構switch case或if (影片)最近在客戶那邊一起 pair 重構 legacy code, 碰到了一大段 if/else statement,用來判斷什麼時候該使用哪一種cache, 並依照不同 cache 的邏輯來決定回傳的內容。 發現還是有蠻多風氣比較封閉的公司對這類型的基本功跟處理不是很熟悉, 可能是對 code smell 不熟,對重構不熟,對 design pattern 不熟,對工具不熟。![[心得]以策略模式重構switch case或if (影片) [心得]以策略模式重構switch case或if (影片)](https://img.youtube.com/vi/zO-NnNC-xyg/mqdefault.jpg)
16
Re: [請益] 這種情況要怎麼重構1. 你不應該去動別人開發中的 code, 除非 pair 或你是有被授權的人. 2. 你可以使用他的 code , 建 common, 但你不應該改回他的部分(理由1). 3. 假設改完會有衝突, 那表示你做的不是重構. 4. 如果完成再重構會花更多時間, 那表示你做的不是重構. 5. 你要用他的 code , 跟你要整理重構, 是兩回事.7
Re: [心得] 花了很多時間重構卻被打槍用舊code我來響應一下,要怎麼說服工程團隊領導重構 拿安全性壓他,資安這東西,大家都懂,但大家也都不專業 舊架構要嘛運行的環境有已知漏洞、要嘛依賴套件有已知漏洞 去 CVEdetails.com 查一下,整理一下已知漏洞高危清單 用魔法對付魔法,「不改的話有問題你要負責嗎?」2
Re: [討論] 重構之前要寫測試 不然不要重構人生在世,吃飯跟拉屎都是要做的,應該沒有人會說, 要先吃飯不然別拉屎,還是先拉屎不然別吃飯。 改扣就是改扣,框個名字自稱叫重構, 是不是不知道,但即使是重構,本質還是改扣。 測試是為了改扣順利,不寫測試還是可以改扣。1
[請益] openssh on windows server我目標想要 增加一個一般user,可以access sftp,我參考 m/zh-tw/windows-server/administration/openssh/openssh_keymanagement 去做,但是只有administrator 可以通,一般user 的部分一直失敗,是跟什麼群組管理 原則有關嗎? 還請知道的人救救我 --