[請益] 解決不了別人的技術債真的是自己問題嗎

作者: bb0x0 (bb0x0)   2019-11-06 23:57:49
又是代po 跟前一篇不同人
直接貼上了不解釋
鄉民好
個人想請益
最近在軟體專案遇到不知所措的問題
即使最近習慣了莫名其妙龐大的程式碼
但要去修改居然會有 人為因素 上的難度
我簡單描述整個程式的狀況
就是class不是有成員函式之類的嗎
本來這個class單體模式就只給一個裝置使用
但因為後來考慮第二個裝置的實作
所以先前人的做法就是…
在一樣的class裡成員函式copy paste然後名稱後面補個2 然後因為又是保持單體模式
就變成一大堆函式都有類似以下寫法
if 裝置一
程式碼一
else if 裝置二
程式碼二
其中程式碼一 和程式碼二幾乎超過百行 根本看不出一不一樣
我想說物件導向的介面不會寫就算了 麻煩重複的程式碼用函式先暫時包起來好嗎…
說到這裡應該高手已經知道怎麼處理這鬼結構 但是 這難度最麻煩的是 人
因為就是某個資深工程師寫
當然已經 溝通過了 但回答是
「那些做法就是debug的時候很好用啊,怎麼了嗎?」
「從頭改需要時間,就算改好程式保證正常嗎?出事誰負責?」
「你能想想現實面的問題嗎?公司不是給你用來玩實驗的。」
「你可以從小地方慢慢改起啊,一定要一次動那麼多地方嗎?」
「拜託請你考慮別人請不要那麼自私。」
然後繼續過著大家加新功能修改功能還要順便整理他很有產量的程式碼。
所以怪我囉?
為什麼我還要配合別人的智商做事情
而且你還待十幾年
連C++好用的語言特性都不會用 更不肯學
還好意思裝忙 說什麼急著趕案子
那種鬼寫法是最拖時間的最玩命的吧
整間公司也莫名其妙
不好好整頓他居然還隨便期待有其他還不到一年的員工
可以解決這個每天被他拉出的x code
我現在是攤手沒輒 不太想再留在那浪費時間
在其他工作我也沒看過如此奇葩的現象
各位看的鄉民覺得是我的錯嗎
作者: yamakazi (大安吳彥祖)   2019-11-07 00:00:00
一次改一部分 然後用自動UT驗 先shelve起來有空再上code不然就新拉一個branch慢慢改
作者: MOONY135 (談無慾)   2019-11-07 00:03:00
我看過 不過那個人一年後還是沒改
作者: MixBear (米克斯)   2019-11-07 00:17:00
這要始作俑者觀念跟著改,就算你改好了 再經他的手最後還是重複循環
作者: chuegou (chuegou)   2019-11-07 00:19:00
我都把前人技術債化為筆記 然後要改code都要先看筆記寫了四五本 每次要找東西也累
作者: viper9709 (阿達)   2019-11-07 00:31:00
這個就標準的疊床架屋...某方面說也算不重視開發
作者: abccbaandy (敏)   2019-11-07 00:33:00
還真沒看過在意code品質的公司...需求時程一下來就什麼都不管了XD
作者: ldkrsi (衰神)   2019-11-07 00:33:00
非一人專案 沒高層支持千萬不要搞重構
作者: neo5277 (I am an agent of chaos)   2019-11-07 01:11:00
開branch加一
作者: vi000246 (Vi)   2019-11-07 01:35:00
反正各人造業各人擔 出事找他就好
作者: tvbic   2019-11-07 02:10:00
別人寫出這種東西是他自己白癡,你想辦法幫他解決那就更白癡了
作者: ko27tye (好滋好滋)   2019-11-07 02:23:00
對主管來說重構 = 沒產出 你敢在咪挺時說這兩個禮拜都在重構嗎
作者: prag222 (prag)   2019-11-07 05:07:00
改了會出錯阿 傻喔 你以為你新人又厲害會重構喔
作者: bndan (seed)   2019-11-07 08:22:00
基本上工作的重點就是做上面認為有產能的事 然後準時領錢下班 在家爽/忙自己的事...除非這間公司的組織真的有讓你想加入的情況 不然就領個薪水盡人事...另外 沒有任何"保證"的情況下重構 這只是坑死自己而已 就算事實上你重構的都是正確的 但"證明"不存在 你可以是解決問題的人 也可以是製造問題的人 XD
作者: flysonics (飛音)   2019-11-07 08:40:00
廢渣耶 這什麼完全浪費物件導向優勢的寫法新案子剛開發的話你可以提倡看看啦 舊的就不要動他了不要沒事擔屎在身上
作者: t19960804 (泥好嗎)   2019-11-07 09:16:00
上級只要能動就好了 你重構他們不會幫你加薪升官
作者: t64141 (榕樹)   2019-11-07 09:47:00
這需要上面支持,而人跟程式碼品質都很差之下,換工作最快對方回話方式這麼帶攻擊性也是很有毛病
作者: as885212   2019-11-07 10:20:00
這就是分工的重要性 分工分的好 大家就用interface溝通內部自己的垃圾程式碼 自己負責至於interface怎麼設計就是另外一個問題了 至少問題縮小又不用管一些垃圾事
作者: popcool (我不懂)   2019-11-07 11:52:00
寫十幾年還是這種觀念,你還是快逃吧
作者: eatpupu (吃大便)   2019-11-07 13:16:00
塊桃R
作者: wuliou (wuliou)   2019-11-07 13:27:00
快陶R
作者: v7q4 ((.)(.)乳劍雙修 -|=>)   2019-11-07 14:31:00
大專案又很多人做一做離職 就會變這種科學怪人...
作者: keyut2433 (keyut2433)   2019-11-07 15:24:00
這人一定沒寫test
作者: hidog (.....)   2019-11-07 15:32:00
為什麼你需要維護他的程式碼? 當事人又還沒離職主管沒講話你管他幹嘛 閒沒事情做嗎 不會去唸英文?
作者: deray (Deray)   2019-11-07 15:47:00
不合就閃人呀
作者: hidog (.....)   2019-11-07 19:12:00
如果是這樣就閃吧 代表主管太廢
作者: jason4571 (terry)   2019-11-07 20:39:00
公司就是要賺錢優先 誰理你重構能幹嘛 辭職唯一解
作者: jefflu   2019-11-08 05:55:00
如果是人硬要擋的原因 那也真的沒辦法... 但是如果只是他提出的問題 那我覺得是蠻小的問題, 你可以自己開一個branch 來改那個東西 確定改的都有test case cover到, 然後rollout的時候用alpha/beta version rollout. 先rollout給0.1%的用戶試beta就可以了 有問題就直接設bets=0 一秒解決問題所以他提的技術問題其實不是問題另外他的寫法debug其實不會比較簡單 他可能真的不太懂寫code...
作者: leveger0903 (脆笛酥)   2019-11-08 10:22:00
前陣子我也重構前同事不知所云的程式碼 不過主管覺得時間太久雖然我們公司不是什麼程式碼很乾淨的公司 但是很討厭不照公司規則走的同事 人離職了留那一坨不知道怎麼維護的代碼 不留git 不寫註解接手的人真的很衰
作者: jones2011 (σ゚▽゚)σ)   2019-11-08 18:56:00
無解,因為既有的很難處理就乾脆無視如果是不同裝置不同初始設定那最好別碰這種code,因為你不知道哪一個才是正確的
作者: pttuser2266   2019-11-08 19:17:00
改下去大不了離職
作者: cha122977 (CHA)   2019-11-08 21:41:00
可以看誰寫的誰負責改 新功能用他的東西就讓他自己改
作者: OhNo386 (OhNo386)   2019-11-09 10:05:00
改不動 可以亂改 解決a bug 產生b bug,解決b bug 產生cbug ,這樣就有很多事可以做了,老闆也會覺得你很忙,無法取代 xd不過比正向的方式還是快點練功 跳到你看code順眼的地方
作者: SHANGOYANYI (彥一)   2019-11-09 15:58:00
欸... 是說別人的code你去動幹嘛?

Links booklink

Contact Us: admin [ a t ] ucptt.com