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

看板Soft_Job作者 (NickLin)時間9月前 (2023/07/28 15:13), 編輯推噓36(40推 4噓 364→)
留言408則, 27人參與, 9月前最新討論串15/17 (看更多)
針對上一篇還是有人在追殺B我就閒來無事重申一下問題點在哪裡 很多人一直糾結於B有沒有複測、B有沒有去追這個Issue，我跟你說跨組合作不是這樣搞 滴 首先要先搞懂這個Ownership的問題 原Po是Feature Owner A是原Po組的寫出有問題Code的Dev QA在原Po組 B的開發建立在A的成果 再來搞懂開發流程的問題 A先開發 B開發需要A的change B發現問題回開Ticket並把自己的Feature完成 重點來了，如果B的code 100%沒問題，這裡B已經完全不需要複測任何東西了，這個Issue 就是A組要解決，你QA測不出來鍋也一起揹 舉個最簡單的例子（非當事）一樣用AB來帶入） 假設OS有個新API叫hundred()需要return 100 B要拿來用在feature上且在UT的時候假設這個API一定return 100所以UT 100%能測過，但 是上環境實測的時候發現有時候是99有時候是100，B開Ticket給A組說你這個API有時候是 99請解決一下，結果A組說他們怎麼測都是return 100所以把Ticket關了且A組QA也說沒問 題 講到這，如果你還覺得B要去複測的話，那你應該叫B去把A組的Code也寫完，因為B怎麼知 道A組的Code竟然會跟環境有關或是跟環境有關但沒有考慮到Corner Case(以原Po的例子 搞不好還不是Corner case，感覺是個Known Case)，要怎麼知道你有沒有重新commit過有 用的code才不能重現，要怎麼知道Feature owner的code review沒什麼用抓不到問題，要 是B都知道這些的話那B應該才是feature owner不是個Principal就是準備升職的人還能讓 你在這甩鍋？ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 172.58.88.43 (美國) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1690528382.A.7E1.html
推
07/28 15:40, 9月前 , 1F
合理
07/28 15:40, 1F
→
07/28 15:47, 9月前 , 2F
因為這個社會需要和諧，所以不修飾言詞的人，要背鍋！
07/28 15:47, 2F
推
07/28 15:49, 9月前 , 3F
合理+1
07/28 15:49, 3F
推
07/28 16:23, 9月前 , 4F
沒用 下面繼續跳針
07/28 16:23, 4F
推
07/28 16:24, 9月前 , 5F
推
07/28 16:24, 5F
→
07/28 17:02, 9月前 , 6F
最初是說，A組認定是 corner case 所以才關掉的吧？
07/28 17:02, 6F
噓
07/28 17:03, 9月前 , 7F
照你這種開發方式B根本不該測試實際接上去 也不該發Ticket
07/28 17:03, 7F
→
07/28 17:03, 9月前 , 8F
因為他只要確保他那邊對就沒事了啊
07/28 17:03, 8F
→
07/28 17:03, 9月前 , 9F
你自己開出來的ticket本來就要驗證被關掉是否是真的解掉吧
07/28 17:03, 9F
→
07/28 17:03, 9月前 , 10F
你怎麼知道對方關掉是真的有理解並解掉你的問題
07/28 17:03, 10F
推
07/28 17:13, 9月前 , 11F
對方關掉還說你環境搞爛是一堆人無視還是怎樣啊？都說你
07/28 17:13, 11F
→
07/28 17:13, 9月前 , 12F
環境不可信了你在自己機器上再驗fail能說明啥？沒在客戶
07/28 17:13, 12F
→
07/28 17:13, 9月前 , 13F
那裡炸開時A和QA認定他們環境才是好的，炸了後還要B來背
07/28 17:13, 13F
→
07/28 17:13, 9月前 , 14F
鍋這真是夠扯…
07/28 17:13, 14F
推
07/28 17:22, 9月前 , 15F
你可能要回去看下原文，原po 是 application owner，
07/28 17:22, 15F
→
07/28 17:22, 9月前 , 16F
B才是feature owner。B知道自己的feature有問題，是
07/28 17:22, 16F
→
07/28 17:22, 9月前 , 17F
A的code造成的。A改過code後，他還是硬開出去，結果
07/28 17:22, 17F
→
07/28 17:22, 9月前 , 18F
是B的feature 讓客戶爆炸。
07/28 17:22, 18F
→
07/28 17:22, 9月前 , 19F
最後他說我的code部分是假設A code 沒問題寫的，我的
07/28 17:22, 19F
→
07/28 17:24, 9月前 , 20F
部分沒問題。但 feature有沒有問題？我沒再複測（至少
07/28 17:24, 20F
→
07/28 17:24, 9月前 , 21F
表面上說沒有）。這樣當然會被懲處，B是 feature owner
07/28 17:24, 21F
→
07/28 17:24, 9月前 , 22F
啊。A的code是改過再回來的，並不是跟前一次相同code。
07/28 17:24, 22F
推
07/28 17:24, 9月前 , 23F
A認為他複製不出來這個問題，肯定是B把自己環境搞砸了…
07/28 17:24, 23F
→
07/28 17:24, 9月前 , 24F
這原po第一篇自己寫的，當初A有這種心態就已經決定會在
07/28 17:24, 24F
→
07/28 17:24, 9月前 , 25F
客戶那裡炸開的結果了，因為A當下已經認定這不是問題，
07/28 17:24, 25F
→
07/28 17:24, 9月前 , 26F
而是B在亂！
07/28 17:24, 26F
→
07/28 17:25, 9月前 , 27F
B如果可以不用測，那專案裏大家都各自開發各自的就好，
07/28 17:25, 27F
→
07/28 17:25, 9月前 , 28F
同理，就算你不是用同事的code，而是引用任一個公開函
07/28 17:25, 28F
→
07/28 17:25, 9月前 , 29F
式庫。當函式庫更版時，你可以說「我假定函式庫都是正
07/28 17:25, 29F
→
07/28 17:26, 9月前 , 30F
確的，只要我的call function code正確，我不須要重新
07/28 17:26, 30F
→
07/28 17:26, 9月前 , 31F
測試。」嗎？
07/28 17:26, 31F
→
07/28 17:26, 9月前 , 32F
不管A/B關係多惡劣，B是feature owner，至少你要保證你
07/28 17:26, 32F
→
07/28 17:26, 9月前 , 33F
交出去的東西在你local是run正常的。你都run不正常或沒
07/28 17:26, 33F
→
07/28 17:27, 9月前 , 34F
run就交，本來不是你的鍋也變你的鍋。
07/28 17:27, 34F
→
07/28 17:27, 9月前 , 35F
我看不懂的點是：為什麼B開的ticket，A的人會有權限可以cl
07/28 17:27, 35F
→
07/28 17:27, 9月前 , 36F
ose。我用過的issue/ticket管理系統都沒這種設計。
07/28 17:27, 36F
→
07/28 17:28, 9月前 , 37F
有點膩了，事主全都離職了，在繼續檢討誰對誰錯根本沒有
07/28 17:28, 37F
→
07/28 17:28, 9月前 , 38F
意義，每個人都有自己認為對的流程，誰都說服不了誰，反
07/28 17:28, 38F
→
07/28 17:28, 9月前 , 39F
正自己能用就好。在網路上想講到贏？
07/28 17:28, 39F
還有 329 則推文
→
07/31 04:19, 9月前 , 369F
麻？讓release過的QA原Po在幹麻？退一百萬步來講，
07/31 04:19, 369F
→
07/31 04:19, 9月前 , 370F
假設他認真是知道有問題還放行也可能是他就不是做醫
07/31 04:19, 370F
→
07/31 04:19, 9月前 , 371F
療系統飛行系統阿，類比的亂七八糟還想戰...
07/31 04:19, 371F
噓
07/31 09:16, 9月前 , 372F
你要自行腦補故事請便 軟工板變小說板 B是親自出餐的那個
07/31 09:16, 372F
→
07/31 09:17, 9月前 , 373F
出事後還自己承認我知道有問題我就是故意讓客人吃有問題的
07/31 09:17, 373F
→
07/31 09:17, 9月前 , 374F
東西來highlight問題 這你覺得OK喔 我的老天
07/31 09:17, 374F
→
07/31 09:18, 9月前 , 375F
B今天死不出餐 或出餐吃死人之後裝無辜 都沒他的事喇
07/31 09:18, 375F
→
07/31 09:18, 9月前 , 376F
自己承認自己專業判斷上這東西有問題還故意出 這才是問題
07/31 09:18, 376F
→
07/31 09:19, 9月前 , 377F
認真知道有問題還放行不是問題 認真知道有問題放行出問題
07/31 09:19, 377F
→
07/31 09:20, 9月前 , 378F
還承認自己本來就知道有問題 故意放讓飛機掉下來highlight
07/31 09:20, 378F
→
07/31 09:20, 9月前 , 379F
問題 你看看你有沒有責任啦
07/31 09:20, 379F
→
07/31 09:21, 9月前 , 380F
重點是 東西是「你出的」 你要是不知哪來的三方也就算了
07/31 09:21, 380F
→
07/31 09:22, 9月前 , 381F
然後你自己仔細看 我從來沒說A跟原PO沒任何責任
07/31 09:22, 381F
→
07/31 09:22, 9月前 , 382F
我說的是 你根本還是完全搞不懂B的「問題」出在哪 XDDD
07/31 09:22, 382F
→
07/31 09:23, 9月前 , 383F
今天B裝死或打死不發 最後其它人發了 爆了 就是個尋常的
07/31 09:23, 383F
→
07/31 09:23, 9月前 , 384F
A出bug QA沒抓到 原PO團隊疏失放有問題的東西給客戶 啊這
07/31 09:23, 384F
→
07/31 09:24, 9月前 , 385F
個大如微軟蘋果的OS 小到某個三方套件都馬稀鬆平常 笑死人
07/31 09:24, 385F
→
07/31 09:25, 9月前 , 386F
但B是自己發 爆了 還承認知道有問題我就故意炸客戶 這圖的
07/31 09:25, 386F
→
07/31 09:25, 9月前 , 387F
是什麼？犧牲客戶 來證明你的論點沒錯嗎？這情商跟三歲小
07/31 09:25, 387F
→
07/31 09:26, 9月前 , 388F
孩差不多
07/31 09:26, 388F
→
07/31 09:28, 9月前 , 389F
今天公司要是B開的 那隨便你阿 但你B是老闆嗎？做這種犧牲
07/31 09:28, 389F
→
07/31 09:28, 9月前 , 390F
公司利益成全自己的事 你覺得你能活嗎 笑死耶
07/31 09:28, 390F
→
07/31 09:28, 9月前 , 391F
被殺頭剛好而已啦 甚至我覺得老板是可以提告的 但今天沒出
07/31 09:28, 391F
→
07/31 09:29, 9月前 , 392F
人命也就算了
07/31 09:29, 392F
→
07/31 09:35, 9月前 , 393F
歷史這種專業人士判斷母湯 但公司硬上的案例滿街都是好嗎
07/31 09:35, 393F
→
07/31 09:36, 9月前 , 394F
之前泰坦號工程師不也是專業判斷潛水艇遲早出事 啊老闆說
07/31 09:36, 394F
→
07/31 09:36, 9月前 , 395F
沒問題 那工程師做了啥？就離職阿不然勒 難道他會留在團隊
07/31 09:36, 395F
→
07/31 09:37, 9月前 , 396F
等泰坦號內爆死一堆人 然後出來對記者說 看吧我早知有問題
07/31 09:37, 396F
→
07/31 09:37, 9月前 , 397F
啊我就是故意放老闆去搞 讓他出事 highlight問題 哈哈哈
07/31 09:37, 397F
→
07/31 09:38, 9月前 , 398F
有這麼低能的 世間也是少見
07/31 09:38, 398F
→
08/01 22:01, 9月前 , 399F
這個舉例就... 首先該客戶吃法就要很特殊 而這個只有
08/01 22:01, 399F
→
08/01 22:03, 9月前 , 400F
少數人知道 例如煮麵的剛好知道了 覺得煮湯的要解決
08/01 22:03, 400F
→
08/01 22:04, 9月前 , 401F
這問題 以免被客戶嫌難吃 然而煮湯的測了半天還是沒
08/01 22:04, 401F
→
08/01 22:05, 9月前 , 402F
發現問題出在哪 明明就很好吃 剛好該客戶是某大人物
08/01 22:05, 402F
→
08/01 22:07, 9月前 , 403F
因為這事煮湯的不知道 最後端出來的還是原來的 該客
08/01 22:07, 403F
→
08/01 22:08, 9月前 , 404F
戶氣炸了給了該店爛評 然後老闆也火了
08/01 22:08, 404F
→
08/01 22:12, 9月前 , 405F
B是有其它身份的人 如果他不是統整的人亦即端麵到窗
08/01 22:12, 405F
→
08/01 22:13, 9月前 , 406F
口的人當然沒事
08/01 22:13, 406F
→
08/01 22:17, 9月前 , 407F
但就是是 也都是這原因才會準他commit的 雖然這應該
08/01 22:17, 407F
→
08/01 22:18, 9月前 , 408F
是其它人的任務
08/01 22:18, 408F
‣ 更多 handsomeLin 的文章
文章代碼(AID): #1amsf-VX (Soft_Job)
討論串 (同標題文章)
完整討論串 (本文為第 15 之 17 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共17篇)
‣ 更多 handsomeLin 的文章
文章代碼(AID): #1amsf-VX (Soft_Job)