Re: [心得] 花了很多時間重構卻被打槍用舊code
我來響應一下,要怎麼說服工程團隊領導重構
拿安全性壓他,資安這東西,大家都懂,但大家也都不專業
舊架構要嘛運行的環境有已知漏洞、要嘛依賴套件有已知漏洞
去 CVEdetails.com 查一下,整理一下已知漏洞高危清單
用魔法對付魔法,「不改的話有問題你要負責嗎?」
保證沒人敢挺身說我負責,就這樣,改善軟體供應鏈的同時,順便重構。
如果有人敢挺身而出,那恭喜,以後背鍋俠就是他了。
--
重構完 經得黑白箱還是其他資安手段嗎 別人也是可以這
樣玩
重構跟資安沒有一定相關。重構之後還是會有cve問題
如果你講的是黑白箱,還比較站的住腳
改的話有問題你要負責嗎
這是挖洞給自己跳吧。到時候有安全問題變成修改的哪個人。
未來有任何CVE變成你要修。
這個不用等重構完,換Business問你feature壞了你扛嗎
改了 有問題你負責 結果你只是基層 負不了責 還不是老大
說了算 天真
修補漏洞ㄧ定要重構?你工作了沒大學生
台灣的資安是拿來檢查的
會發這篇的感覺雷包
資安跟重構的關係是?
真是屁話,如果改了出問題,剛好麻煩你負責囉
對啊高裝檢資安 連主管機關一看都有自己違反自己下規定
呵呵 如果客戶 外部沒反應問題一般都當作沒事 而且還要確
定要修改部分有資安問題當重構理由
一堆都iso出來的跟你在paper work 實際上怎樣 就跟台灣的
iso一樣
樓上說得好 我還被資安要求過變數名稱不可以叫password
不然你變數取叫 colin 意思是 口令
命名這件事還確實有道理
在可以反組譯的包體 解開之後先找的就是那些關鍵字
譬如說把編碼的key直接寫在程式碼裡面
變數名叫colin XDDD
命名這件事以前有道理,現在沒有。程式碼混淆技術都出來多
久了。
我覺得假設原始碼一定會被偷 而且一定可以被攻擊者理解
在這個前提下開發系統再去考慮資安問題才是有道理 畢竟
你防不了離職員工
這句一出來 以後出問題就是你負責
改的話有問題你要負責? 你又憑什麼負責? 講笑話大隊?
從負責的角度來看 主管會拒絕重構就是因為他覺得你不夠
格負責 不是什麼組織都能推基層出來全坦的
推樓上
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年)
3
[情報] 『1800 神魔特別報告』神魔工程師阿力山情報來源網址: 大家好我是『神魔改革行動部』的神魔工程師阿力山大。歡迎大家觀看『1800 神魔特別 報告』。![[情報] 『1800 神魔特別報告』神魔工程師阿力山 [情報] 『1800 神魔特別報告』神魔工程師阿力山](https://i.imgur.com/k7kxw6gb.jpg)
16
Re: [請益] 這種情況要怎麼重構1. 你不應該去動別人開發中的 code, 除非 pair 或你是有被授權的人. 2. 你可以使用他的 code , 建 common, 但你不應該改回他的部分(理由1). 3. 假設改完會有衝突, 那表示你做的不是重構. 4. 如果完成再重構會花更多時間, 那表示你做的不是重構. 5. 你要用他的 code , 跟你要整理重構, 是兩回事.16
Re: [問卦] 「Cubo Ai 寶寶攝影機」真的不行了嗎?看到推文提到重構,我想說的是 在台灣,重構,本來就是做功德 你今天發現公司的軟體技術債多到靠盃, 人家花一天就能搞定的功能你們公司要花三天, 換句話說,公司浪費了接近七成的工程師薪水在技術債上。15
Re: [請益] 這種情況要怎麼重構我這篇寫的跟原原PO的狀況無關 ※ 引述《tbpfs ( )》之銘言: : 其實我真的不懂為什麼要急著重構 : 有好處嗎? : 一般而言,重構都是發生在農閒的時候2
[情報] 神魔之塔王者盃「已知問題」判定公告情報來源網址: 神魔之塔王者盃「已知問題」判定公告 神魔盃團隊現判定以下「已知問題」為不犯規: 「搶轉」 定義:在敵人完全呈現前,選手移動符石(轉珠)或發動攻擊。![[情報] 神魔之塔王者盃「已知問題」判定公告 [情報] 神魔之塔王者盃「已知問題」判定公告](https://i0.wp.com/towerofsaviors.com/wp-content/uploads/2020/05/appicon_v19.00_ios.png?fit=1020%2C1020)
2
Re: [請益] 這種情況要怎麼重構如果專案有deadline的壓力建議是先各自發展以不相互影響為前提,最後再用剩餘時間開 一個分支做重構。其實這就是在規劃專案時沒有一個主要主導的設計人,沒有定義從系統 到功能的分工,導致代碼重工,而且缺乏溝通。 真的建議未來有機會在主導你還是要自己學會定義好工作,先學習不寫code就可以訂出功 能以及架構。我自己工作後常常遇到工程師很喜歡自幹,還沒開始就急著寫code,而不是