Re: [心得] 我在科技業遇到的鬼故事之一

看板Soft_Job作者 (NickLin)時間9月前 (2023/07/28 02:54), 9月前編輯推噓61(63推 2噓 187→)
留言252則, 21人參與, 9月前最新討論串13/17 (看更多)
閒閒沒事來回第三篇繼續捍衛一下B 我拿我自身經驗分享一下，我在亞麻在Amazon模改的Android OS底下開發過Android Appl ication，雖然不完全一樣但是應該有點相似 首先是討論開Ticket關Ticket的問題，如果今天用新的OS版本炸掉過一次我開Ticket給OS 組，OS組回說不可能有問題然後我也剛好沒法在重現的話，肯定是讓Ticket關了，Reopen 的條件是我馬上能在Repro一次 原因很簡單：我不負責你組的Code我不可能去看你的Code然後再跟你說你哪邊有Risk，且 確實也有可能是我自己的錯誤（環境、我自己的Feature沒寫好等等），如果你拍胸脯保 證你的OS change沒問題能進版，我在app組有什麼能力去Block你？我最多也只會在會議 裡稍微提醒說要注意畢竟沒遇過第二次，那這個問題你們整組都知道了我想絕對不是一次 溝通而已 那你說B自爆說硬要highlight這個問題，我是覺得高機率是屁話或純粹跟你們吵架而已， 他自己肯定不可能100%Repro，如果會100%發生他要怎麼開發？搞不好你走到他機器旁邊 就遇到資料毀損呢，感覺是你們組太常搞被開Ticket不解決就關的問題，這次讓你們知道 嚴重性而已 希望你們在職場上永遠不要成為B，發現Bug還要被Bug Owner甩鍋責備發現過還不堅持到 底，謝謝大家 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 70.183.16.146 (美國) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1690484070.A.F8E.html
推
07/28 02:56, 9月前 , 1F
但是B最後的自我辯護不是無法repro，而是完全沒作。
07/28 02:56, 1F
→
07/28 02:56, 9月前 , 2F
然後沒測就開出去了。
07/28 02:56, 2F
→
07/28 02:57, 9月前 , 3F
如果真的測了但無法repro，其實他不需要說謊。
07/28 02:57, 3F
推
07/28 03:04, 9月前 , 4F
只測一次是B自己講的，100% repro也是B自己講的，所以
07/28 03:04, 4F
→
07/28 03:04, 9月前 , 5F
只測一次就失敗，回報後也不複測的B，還是開發完了還
07/28 03:04, 5F
→
07/28 03:05, 9月前 , 6F
其實B沒有義務repro並跟進這個bug那是A組的事
07/28 03:05, 6F
→
07/28 03:05, 9月前 , 7F
release出去，如果他不是故意才更恐怖吧，代表他都是閉
07/28 03:05, 7F
→
07/28 03:05, 9月前 , 8F
著眼開發。
07/28 03:05, 8F
→
07/28 03:06, 9月前 , 9F
現在根本沒有B現身說法唄，是只重現出一次或沒有重現出來
07/28 03:06, 9F
→
07/28 03:07, 9月前 , 10F
照上篇說法，B至少要UT，所以第一次 UT 失敗開Bug。
07/28 03:07, 10F
→
07/28 03:08, 9月前 , 11F
沒完成UT當然責無旁貸。除非他說第二次UT無法repro。
07/28 03:08, 11F
→
07/28 03:08, 9月前 , 12F
但他是説第二次他沒UT。
07/28 03:08, 12F
→
07/28 03:11, 9月前 , 13F
這分兩部分，UT自清或者UT高光
07/28 03:11, 13F
→
07/28 03:11, 9月前 , 14F
不論他UT自清做到百分之一百都不是老闆想知道的
07/28 03:11, 14F
→
07/28 03:12, 9月前 , 15F
老闆要知道這個已經在客戶爆炸的bug的UT有沒有測
07/28 03:12, 15F
→
07/28 03:13, 9月前 , 16F
究責的是UT高光有沒有跑徹底，至於自清沒做到那是延伸
07/28 03:13, 16F
推
07/28 03:15, 9月前 , 17F
他的UT工作跟自清或高光無關吧，本職上就是UT自己這關
07/28 03:15, 17F
→
07/28 03:15, 9月前 , 18F
的東西確認沒問題才交下一關。
07/28 03:15, 18F
→
07/28 03:15, 9月前 , 19F
這種情境要回應老闆認為的UT，簡單來說就是回應沒有做到
07/28 03:15, 19F
→
07/28 03:18, 9月前 , 20F
看了好久我看不懂你的意思，什麼是自己這一關
07/28 03:18, 20F
推
07/28 03:20, 9月前 , 21F
流程： A code (UT) -> B(UT)(整合)(UT) -> QA
07/28 03:20, 21F
→
07/28 03:21, 9月前 , 22F
不管有沒有 Bug 都是這流程，所以B第一次回退後，A
07/28 03:21, 22F
→
07/28 03:22, 9月前 , 23F
你是要說B UT自清 還是整合UT高光
07/28 03:22, 23F
→
07/28 03:22, 9月前 , 24F
close後再送過來的東西，B還是要UT和整合完才下一步。
07/28 03:22, 24F
→
07/28 03:23, 9月前 , 25F
整合不也是UT，什麼叫作UT和整合
07/28 03:23, 25F
→
07/28 03:23, 9月前 , 26F
B無責：A code -> B UT無法復現 -> QA
07/28 03:23, 26F
→
07/28 03:23, 9月前 , 27F
B重責：A code -> B UT復現，故意放過-> QA
07/28 03:23, 27F
→
07/28 03:24, 9月前 , 28F
B輕責：A code -> B 沒UT -> QA
07/28 03:24, 28F
→
07/28 03:26, 9月前 , 29F
UT（Unit Test）整合（integration）IT(integ. Test)
07/28 03:26, 29F
→
07/28 03:26, 9月前 , 30F
A掛理想B behavior driver UT PASS，B 掛理想A behavior
07/28 03:26, 30F
→
07/28 03:26, 9月前 , 31F
driver UT PASS
07/28 03:26, 31F
→
07/28 03:28, 9月前 , 32F
退一萬步是整合UT沒測過
07/28 03:28, 32F
推
07/28 03:28, 9月前 , 33F
但B是說他第二次完全沒作UT。
07/28 03:28, 33F
→
07/28 03:30, 9月前 , 34F
沒什麼「掛理想對方作過」，照上篇原PO提到公司流程，
07/28 03:30, 34F
→
07/28 03:30, 9月前 , 35F
前文沒有提到是指B掛真A的UT，或者B掛A BM的UT 阿
07/28 03:30, 35F
→
07/28 03:30, 9月前 , 36F
每個環節都要自己作UT。
07/28 03:30, 36F
→
07/28 03:31, 9月前 , 37F
每個環節都要，這不就是系統測試了
07/28 03:31, 37F
→
07/28 03:36, 9月前 , 38F
我不是刁難，而是自己的每個環節都要UT，與整合後的每個
07/28 03:36, 38F
→
07/28 03:36, 9月前 , 39F
環節的UT，這兩個落差很大
07/28 03:36, 39F
還有 173 則推文
還有 2 段內文
推
07/28 13:04, 9月前 , 213F
我就說當下A部門怎樣都贏，但在客戶那裡炸了還回來找B究
07/28 13:04, 213F
→
07/28 13:04, 9月前 , 214F
責真是可怕…
07/28 13:04, 214F
→
07/28 13:04, 9月前 , 215F
現在講都事後諸葛，回到release前看，QA測沒事，A測沒事
07/28 13:04, 215F
→
07/28 13:05, 9月前 , 216F
CICD(不知道有沒有）有過，就B的local有問題，那怎算？
07/28 13:05, 216F
→
07/28 13:05, 9月前 , 217F
w0說的並沒發生 因為往不同方向發展了 是要討論別的案子嗎
07/28 13:05, 217F
→
07/28 13:07, 9月前 , 218F
就B原本是救世主, 但不知為何後來裝沒看到, 微笑插刀
07/28 13:07, 218F
→
07/28 13:11, 9月前 , 219F
w0說的就是原原PO描述的release前的事實啊
07/28 13:11, 219F
推
07/28 13:11, 9月前 , 220F
A部門一開始真把B當救世主就不會在客戶那裡炸了
07/28 13:11, 220F
→
07/28 13:13, 9月前 , 221F
不要人當初都被你們殺了，事後需要時再來封聖好嗎
07/28 13:13, 221F
推
07/28 13:44, 9月前 , 222F
我是指w0講delay客戶跑掉那段
07/28 13:44, 222F
推
07/28 13:44, 9月前 , 223F
B的local沒測過就是把環境和repro證明錄下來證明就好了
07/28 13:44, 223F
→
07/28 13:45, 9月前 , 224F
只要有人環境沒測過就是要找環境或code哪有問題
07/28 13:45, 224F
→
07/28 13:46, 9月前 , 225F
你能復現就不會是你問題，現在是B除了一開始說有問題後
07/28 13:46, 225F
→
07/28 13:46, 9月前 , 226F
就不管了，也不提供驗證方法，最後也不複測。
07/28 13:46, 226F
→
07/28 13:47, 9月前 , 227F
不然就是你復現不了，那也不會有你責任。
07/28 13:47, 227F
推
07/28 14:38, 9月前 , 228F
檢討B根本沒用 來個CDEF還不是一樣 該討論的是怎麼擋
07/28 14:38, 228F
→
07/28 14:39, 9月前 , 229F
好啦 就讓B被火 然後CDEF還是一樣 你天天都在管人而已
07/28 14:39, 229F
→
07/28 14:40, 9月前 , 230F
每天問底下所有員工是不是有不爽就好啦 事情都不用做
07/28 14:40, 230F
推
07/28 15:43, 9月前 , 231F
就算客戶沒跑，feature因為一個RD自己也無法重現的local
07/28 15:43, 231F
→
07/28 15:43, 9月前 , 232F
test fail而delay，你覺得他不會被HL更嚴重？
07/28 15:43, 232F
→
07/28 15:48, 9月前 , 233F
B堅持不開feature，大家就覺得在無理取鬧而已，根本沒用
07/28 15:48, 233F
→
07/28 16:34, 9月前 , 234F
講真的 主管只是遷怒B而已 有問題的是A跟QA
07/28 16:34, 234F
→
07/28 18:32, 9月前 , 235F
他是指環境如果錯了100%復現 環境對了0%復現
07/28 18:32, 235F
→
07/28 18:33, 9月前 , 236F
他也只測一次就肯定問題還是有 不然也不用說要
07/28 18:33, 236F
→
07/28 18:33, 9月前 , 237F
highlight什麼
07/28 18:33, 237F
→
07/28 18:35, 9月前 , 238F
很多人會把B說詞往亂講話的方向解讀 可是沒有足夠的
07/28 18:35, 238F
→
07/28 18:35, 9月前 , 239F
證據 都是各位的自由心證
07/28 18:35, 239F
→
07/28 19:43, 9月前 , 240F
要明說客戶是錯的就直說唄，不用繞圈子講
07/28 19:43, 240F
→
07/28 19:45, 9月前 , 241F
明白表示客戶用錯，所以資料蒸發了也是客戶要take care
07/28 19:45, 241F
→
07/28 20:03, 9月前 , 242F
這事件誰去責怪客戶？ 不要打迷糊仗 認為B有問題不代
07/28 20:03, 242F
→
07/28 20:03, 9月前 , 243F
表認為客戶有問題 兩個綁在一起是在詭辯是嗎?
07/28 20:03, 243F
推
07/28 21:12, 9月前 , 244F
B的問題不是他的環境，是他自己own的程式爆了還放過的
07/28 21:12, 244F
→
07/28 21:12, 9月前 , 245F
作為。
07/28 21:12, 245F
噓
07/29 05:48, 9月前 , 246F
B這種心態也有人挺，真的笑死。
07/29 05:48, 246F
→
07/29 06:23, 9月前 , 247F
整個團隊就是各個組自己爽，沒人敢跨部門要，職場這樣
07/29 06:23, 247F
→
07/29 06:23, 9月前 , 248F
正常啦
07/29 06:23, 248F
推
07/30 20:02, 9月前 , 249F
大家有發現我們知道的B，只是由他人轉述來的
07/30 20:02, 249F
噓
07/30 21:49, 9月前 , 250F
不好意思 關鍵就在他「直接講要highrlight這問題」
07/30 21:49, 250F
→
07/30 21:49, 9月前 , 251F
你管不到別人家的東西測不出來 就要裝無辜裝死到底OK？
07/30 21:49, 251F
→
07/30 21:50, 9月前 , 252F
這一點人情世故都不懂
07/30 21:50, 252F
‣ 更多 handsomeLin 的文章
文章代碼(AID): #1amhrc-E (Soft_Job)
討論串 (同標題文章)
完整討論串 (本文為第 13 之 17 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共17篇)
‣ 更多 handsomeLin 的文章
文章代碼(AID): #1amhrc-E (Soft_Job)