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

針對上一篇還是有人在追殺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