Re: [討論] 系統越開發越多,負責的東西越來越多
※ 引述《w0005151 (藍廳)》之銘言:
: 找人的時間成本八成也是落到你身上,花你的時間去面試跟訓練
: 平常該寫的文件就寫
: 能分享的知識就分享
: 該丟出去的事情就丟
: 短期解決不了的神奇邏輯,補個註解跟文件連結
: 不要讓自以為聰明的新人改掉,最後爆炸還是你來修
(恕刪)
: 問題是身為資深成員的你,可否提出數據說明工程宅們整天在吵的code quality到底跟業: 務的關係在哪
: 是不是做同樣規模的feature要花的時間越來越多
: 是不是release後常常出問題要修
: 是不是客人抱怨的頻率越來越高
: 是不是工程部門離職率越來越高
: 數據拿出來,我不信老闆或PM不關心
這位大大說得我覺得很有道理 不過太理想了
我就分享台灣某間 威X科技資深員工的作法
這間公司的C++寫得跟屎一樣 一個function五六千行 一堆magic number跟if else
數不清的global variable跟把變數當register用(我看到那種寫法以為在ASM
還有一堆明顯能Extract Method解決的重複snippet
至於你說數據拿出喔....
PM&老闆心想: 阿不就是工程師在找藉口
要重構你可以自己"找時間"重構啦
公司要賺錢 所以當然繼續塞功能進來 不是嗎?
不過啦 這間公司有個規則 就是你code改壞壞了 要負責任
所謂負責任 就扣錢錢
但你要開發新功能 不可能不用到、不改到舊的code吧?
於是某個老屁股想出一個天才的方法
就是把每段舊的function複製出一份 然後再依據他自己的需求更改
於是公司的程式碼每年都以倍數成長 好幾個function都有一個相似度高達87%的兄弟
這個team除了這老屁股外 離職率越來越高、bug越來越多
但是這老屁股自己都沒事 績效還越來越好 有球就往別人身上踢
每次有員工離職 RD大主管都會進行訪談 離職的員工都抱怨code quality太差
最後大主管終於發現到 根本不可能繼續這樣下去
於是又聘了一堆人馬 真的是要打掉重練重寫整個系統
所以我給原原PO的建議就是:
1. 高產能的方法就是複製code 你只要自己的功能跟績效能完成就好
這樣改不到舊的code 也不會有bug 人家看你的commit ++數 哇 每天寫好多扣扣
2. 不要傻傻地跟上層提什麼建議或數據
人家帶領得多棒 你整天喊重構的小朋友董個P?
你怎麼不讓那些剛進職場傻傻的、終於忍不住離開職場的 去發表意見
我的觀察啦 會重視code quality的主管跟公司吼
不用你講就會行動了啦
阿不會重視的吼 講再多..... 可能有用啦 據理力爭嘛 拿出數據拿出研究報告拿出佐證
但你怎麼不讓別人去說呢?
--
高頻ㄇ
哈哈 不是啦
這篇才正解,主管可以靠讓新人繼續弄糞扣拿績效才會升
的快啊,除非哪天他發現底下人寫不下去了才會要重構啦
,但他早爽爽升官加薪,而你沒份啦
藍大那篇前半段還能認同 後半就算了 都底層工程師提出
那不知道要主管幹嘛 在台灣提出太多還會被上層黑
我覺得還是看主管風格做事,主管也想改變的再提出建
議,沒有的話就乖乖找下一家公司
大家都是提離職才會一起講出來啦
真好笑,你一個資深技術人員遇到問題拒絕思考怎麼改善
要是升上去當主管一樣是變成只會壓榨底下工程師的..
幹差點以為在說我,但是大家都各做各的也差不多
寫扣就跟貓糧一樣,明天過後就不新鮮了
我也曾經想改善,努力學習努力重構,但後來發現無論你多
努力寫好程式,你同事們還是努力製造屎坑,對他們而已早
下班最重要,程式品質是啥鬼,所以同事的觀念才是關鍵,
努力尋找好公司比你努力去改善現況更有意義
有思考執行不了沒意義,在某些人眼裡別人改不動是他的不
可取代性,受不了人跟團隊趕快跑實在
推 真的不用沒事找事做
推這篇,上一篇真的太理想,KPI從沒聽過是非業務的
這篇感覺比較符合我的經驗
哈哈 一個function 五六千行的公司也在待
整天拿三流公司來舉例
哈哈 a了一下 這間大概開的待遇是你五年前拿到offer的三倍左右啦 code是真的三流啦 薪水...嗯~可以解釋為什麼有人能待那麼久啦 很多技術人員有誤解 因為實際賺錢的公司 code不見得多好
※ 編輯: SkankHunt42 (86.107.104.242 香港), 10/28/2023 15:48:45非常務實. 我不能說你錯.
管理學就是要看現場情況 這是自然演化
南無阿彌陀佛
嘻嘻有人被打臉馬上就刪舊文,薪水能領多高跟程式碼品
質真的沒太大關係好嗎
坐我隔壁一個寫十年的工程師,寫個method東抄抄西抄抄
連Error Handling都不處理直接交差的,還不是靠年資領
比我多,過幾個禮拜我擴功能還要幫他抓漏想到就氣XD
推非常現實面的職場現況,我相信有理想化的職場,但我更相
信有99%都是這位大大說的情形
哈哈 就是待過三流公司才知道啊
不然誰還會假日跟你在網路抬槓
看不出來假日在網路開槓跟三流公司的關聯性在哪 哈哈
錢才是真的 錢多就安靜了
確實,樓上中肯T_T
這篇比較貼近現實
推,很務實的作法
這情況,讓我想到某金融產業...
有沒有一種可能是你待過的公司都是這樣的文化而不是人家
太理想。
解舊的issue可以算performance嗎@@
糞code給新人接,寫出來的糞code給新人維護,績效自己拿,維
護出包新人揹
哪家
好可怕的寫法,這樣可擴充性一定超差,bug埋的到處都是….
推你,現實和理想總是有差距的
46
首Po在公司待了好幾年,開發的系統越來越多。每個開發時都要搞懂一些新的業務邏輯,上線後 還要後續維護,有問題還要幫忙解決。 但我常常在想,人力沒變,但我身上的loading卻越來越重,現在的我比三年前的我多負責 了一堆系統問題,這樣是合理的嗎? 大家的公司都是這樣的嗎?31
合理啊,進來這麼久了 對於程式碼和領域的掌握度,一定比幾年前的自己好上許多吧 一樣的工作量以前要做兩個禮拜,現在可能三天就做完了 當然要能做更多的事情 不然公司為什麼要給你更多薪水?32
推 yangs0618: 推個 希望有機會聽到進一步分享how 10/28 07:58 → yangs0618: On提出數據說服主管/管理層 開發是越來越耗時間 10/28 07:59 → panbanana: 要怎麼跟上頭說開發越來越久跟code quality有關 10/28 08:18 幾個很簡單的學術名詞就能說明,我相信大家也知道 耦合性 如果我改A模組,B模組就需要跟著改 (這還是B模組沒有牽連其他模組的情況下)17
微服務似乎可以改善一點這方面的問題 系統開發有點像是公司還很小的時侯 當你公司還很小的時侯 某個職員要當客服 又要兼倉管 又要兼銷售 所以這個職員可以拿到各種不同的數據
78
Re: [心得] 我在科技業遇到的鬼故事之一我是原po,我來交代一些細節,供大家參考一下。 角色: 我在這裡的角色是application owner,我要推一個應用給客戶去使用。 我這個application需要多個feature來組成,B是我其中一個feature owner。 B這個feature需要多個kernel function整合才有辦法達成,當然B自己也要寫不少code。67
Re: [請益] 接手外包商的code沒交接也沒人可以問我的第一份跟第二份工作都是這個樣子,一開始你會像麻痺的人,給你幾個建議 1. 掌握啟動前的入口 - 大部分程式語言都會有一個從作業系統下命令開始執行 的進入點,可能會載入 config、環境變數、命令參數這些東西,你要先清楚 這些東西的配置意義是什麼。 2. 掌握啟動後的入口 - 如果是 server 或常駐程式,在執行階段就會有監聽行為。35
[討論] 重構跟kpi的考量假設以下情境 有個功能A、B都會用到相同邏輯,且有兩份重覆的code (沒有unit test保護,而且年久失修 要加入unit test會需要更多時程) 現在要加入C,也會用到相同邏輯 身為合格的工程師 應該會把ABC重覆的部份提取出來24
重構的幾個迷思覺得最近很多文章都有些不求甚解的問題,來寫點論述。 1. 重構不是什麼了不起的事情 2. 變更程式碼,重寫舊的程式碼成自己爽的樣子,不一定是重構。 3. 重構是一種相對安全的工具型開發方法論, 但仍然有不少風險跟誘惑。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, 歷史包袱的... 如果你的主要考量是這個系統太爛不想改他 那我會建議不要離職. 因為不管你走到哪,都會遇到一樣的問題