Re: [心得] 我在科技業遇到的鬼故事之一
閒閒沒事來回第三篇繼續捍衛一下B
我拿我自身經驗分享一下,我在亞麻在Amazon模改的Android OS底下開發過Android Application,雖然不完全一樣但是應該有點相似
首先是討論開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甩鍋責備發現過還不堅持到底,謝謝大家
--
但是B最後的自我辯護不是無法repro,而是完全沒作。
然後沒測就開出去了。
如果真的測了但無法repro,其實他不需要說謊。
只測一次是B自己講的,100% repro也是B自己講的,所以
只測一次就失敗,回報後也不複測的B,還是開發完了還
其實B沒有義務repro並跟進這個bug那是A組的事
release出去,如果他不是故意才更恐怖吧,代表他都是閉
著眼開發。
現在根本沒有B現身說法唄,是只重現出一次或沒有重現出來
照上篇說法,B至少要UT,所以第一次 UT 失敗開Bug。
沒完成UT當然責無旁貸。除非他說第二次UT無法repro。
但他是説第二次他沒UT。
這分兩部分,UT自清或者UT高光
不論他UT自清做到百分之一百都不是老闆想知道的
老闆要知道這個已經在客戶爆炸的bug的UT有沒有測
究責的是UT高光有沒有跑徹底,至於自清沒做到那是延伸
他的UT工作跟自清或高光無關吧,本職上就是UT自己這關
的東西確認沒問題才交下一關。
這種情境要回應老闆認為的UT,簡單來說就是回應沒有做到
看了好久我看不懂你的意思,什麼是自己這一關
流程: A code (UT) -> B(UT)(整合)(UT) -> QA
不管有沒有 Bug 都是這流程,所以B第一次回退後,A
你是要說B UT自清 還是整合UT高光
close後再送過來的東西,B還是要UT和整合完才下一步。
整合不也是UT,什麼叫作UT和整合
B無責:A code -> B UT無法復現 -> QA
B重責:A code -> B UT復現,故意放過-> QA
B輕責:A code -> B 沒UT -> QA
UT(Unit Test)整合(integration)IT(integ. Test)
A掛理想B behavior driver UT PASS,B 掛理想A behavior
driver UT PASS
退一萬步是整合UT沒測過
但B是說他第二次完全沒作UT。
沒什麼「掛理想對方作過」,照上篇原PO提到公司流程,
前文沒有提到是指B掛真A的UT,或者B掛A BM的UT 阿
每個環節都要自己作UT。
每個環節都要,這不就是系統測試了
我不是刁難,而是自己的每個環節都要UT,與整合後的每個
環節的UT,這兩個落差很大
B的東西要用到A,所以B的UT一定會包含到A的code
不是UT階段就是IT階段。
有人UT有在掛別人的code UT的嗎?這還叫UT嗎? 那怎麼不說A在UT的時候就發現問題? 要是今天有C有D,D發現問題難道叫D解決?我是不相信B今天自己測不過敢交啦,自己的 環境都會炸了怎麼可能交,你說OS每天在炸我開發我還能交,要是這麼好Repro我還不一 秒鐘拿給隔壁組看個三百次還要拖三個禮拜? 你這種態度不就最接近Customer端的人最衰,反正底層的人亂寫只要說上面的人不好好測 就拍拍屁股走了?
如果貴單位覺得合理,那我承認是我錯了
啊不是,不管A寫的code怎樣,B自己要交給QA的東西自己
都說沒測過,怎麼樣都說不過去吧。
對對,太不禮貌了
大家不睡覺在聊工作的事也太辛苦了吧
也是碰過有一派會說他自己寫完不用測整套,直接給QA去驗merge
起來的
關鍵在於該公司的UT,是在開發者電腦上自測的而且沒有記錄
。這種體制,有沒有UT其實不重要了,UT 淪為自由心證。該
公司根本沒有正常有經驗的管理者。
當然淪為情緒與政治之爭。
如果UT是在第三方測試電腦上,B只要能成功執行Bug一次,其
他人自然也容易復現Bug,也沒那麼多問題了。
有沒有UT,竟然是靠嘴巴說出來的,而且大家還採信,真是奇
葩公司啊。
B的UT就只是確保B自己code沒問題就好了吧 B做事類似開發UI把A
的function給使用者點 至於點下去不會爆炸 那是A的UT要做的
事
沒有模擬環境的測試,UT再多也是另一回事阿
這裡有個點是我覺得A這邊最該負責的,那個A要關掉bug時
已經說是B把環境搞砸,那這時候B要UT什麼?B真的UT且fai
l那也符合A說的B搞砸環境啊
B這時候無法證明自己環境沒問題也只能用在A和QA的環境下
跑沒問題的結果當UT不是嗎?
當然最正常的情況應該像DrTech講的,不然在被A判斷為環
境搞砸時,B即使在自己機器上複驗fail也已經沒有意義
OS修好 B是feature owner總是要測過一遍吧? 這邊的
問題是B自己說他知道還是會炸 不是你說的剛好沒辦法
重現
B說還是會炸其實沒啥問題,因為A已經說B搞砸環境了,那
就算B的環境一直fail也符合A認為可以關掉bug的條件啊
最上層 或者最接近customer端的本來就最衰 底層出了
問題如果死不承認 大家還是會去追UI面 變成你要去證
明是底層的問題
B有部分責任我是沒意見,但要說B故意炸客戶或是主責我認
為完全沒道理
B一開始就自己說要故意炸客戶來HL啊,之後調查B主管才
提出追加解釋。所以原PO才說,如果B講的真話而不是氣話
那就非常嚴重。
檢討B的心境到底有什麼魔力?看到不少人包含原po很愛討
論這個,正常公司就是去檢討A那端為何攔不了,盡力去補
強最原始的漏洞,檢討B真的有助於公司的流程改善嗎
說B不敢交,但他就真的交了,不管是因為(1)他自己說沒
測,或(2)他測了沒過還是硬交,現實就是他交了。
除非是(3)他測了,沒法復現,所以安心交了。但他自己否
認了這條路...
檢討B很重要,就像B知道輪胎有問題,還故意組裝到車上
害死人後,他不能說「輪胎又不是我作的,跟我無關。」
B主管也知道不能這樣講,所以才改成「B組裝完沒再試開
過,所以他只是猜測輪胎有問題,不是故意。」
B發現的問題被A說是B搞砸環境啊,你A先扣人家這樣一個大
帽子再來說人家沒複測?我就問B複測fail的話不是符合A講
的B環境有問題嗎?還是B要自證環境沒問題?那A說B環境有
問題前有先提供證明嗎?
B是嚴重懷疑輪胎有問題,原廠回信說你搞錯了,是測試方
法有問題,B鼻子摸摸把輪胎裝上去結果出事死人,那請問
誰該被優先檢討呢
在A說B搞砸環境後B複測兩種結果基本上都是自己有問題啊
,pass就是當初自己步驟有問題,fail就是A說的環境搞砸
不可信,在那個當下A部門就穩贏的,現在還在意那個複測
?
事後調查輪框上有一顆螺絲規格不合(LAGG)
今天B還可能要裝5種輪胎,B也只能看看每個輪胎外觀是否
有明顯毀損,真正該知道問題並且有能力把問題修復的也
只有原廠,
事後出事B就在mur mur,那個我早就知道會出事了啦,請
問這個系統我們該優先檢討誰呢
B不裝輪胎還會被上面的老闆罵 原廠都跟你說沒問題了 還不裝
現在就是B自己說他第二次連外觀都沒看就放行了
這兩次code不一樣喔,B不管這Bug有沒有修,都要重測吧
你問我就是B, 因為B反應問題卻不協助處理, 要A自己通靈
而且B說的不是「我早知有問題」而是「我早知有問題但是
原廠是說無法重現B說的狀況, 不是說沒這回事
故意裝上去要看它出事。」
今天很多人糾結B沒有再測一次,那請問輪胎師父收到原廠
回覆沒問題的回信後,請問輪胎師父要繼續跟原廠說,你
的輪胎就是有問題,找出問題再回我一次,這樣更不合理
吧
原廠送來第二顆輪胎了喔,不是原本那顆。
就說A沒保證沒問題, 是說測不出資料毀損的狀況, 中文不好?
原PO和A有改過code重新commit。
在當下B在自己電腦上測已經沒任何意義了啊,環境被判定
搞砸,那用A和QA的環境來測試當結果有啥問題?
那是只是用猜測問題點來改(就是在通靈啦), 並非針對問題點
正常流程也是要找出B環境的問題,萬一客戶跟B同環境呢?
A認為他複製不出來這個問題,肯定是B把自己環境搞砸了…
這首篇原po自己寫的,誰中文不好?
後來證明也是。
A懷疑B環境有問題是A要證明還是B
關鍵的LAGG是誰的, 有沒有問題, 就原PO文章我看不出來
A和B要一起查,這沒法靠單邊找出來問題。
所以說兩邊不願意合作就要叫主管。
還是我們這邊請主管說有沒有讓 A B合作找問題 XD
要找出B環境問題完全同意,但我自己認為這是在A被開iss
ue這段時間該做;就像原廠收到輪胎問題不能確定,起碼
跟輪胎師父說先緩緩不要裝,而不是回信說是你環境有問
題
A只寫無法復現吧,系統上通常不會白目去標是B有問題。
如果去車行換輪胎, 結果輪胎脫落, 是找車行還是原廠
找車行,然後師父裝的按照流程,就會找原廠 我猜啦
然後車行發現原廠胎有瑕疵, 之前也有發現鎖不緊的情況
對啊 但原廠說沒問題不是嗎 還是師父比原廠懂輪胎
車行有跟原廠反應, 但原廠說經測試無論胎脫落的情況
先找車行找出問題,但假設是原廠說沒問題的輪子出包,
所有因輪胎脫落造成的損害要跟原廠求償
所以車行照常交車給客戶, 害客戶出車禍
後續文章資料就不齊全了 => 後來車行發現同時安裝LAGG會
後來車行發現同時安裝LAGG會導致輪胎脫落
這邊LAGG是不是原廠, 有沒有瑕疵, 文章都看不出來
按照原文 LAGG 是客戶車上有的歐,不是師父另外裝的
吧
問題就是B自己說他確信輪子會出包,故意裝上去要HL原廠
只知道不要同時安裝LAGG(或LAGG已修正? 修掉?) 就沒事
對 就是剛好LAGG客戶的車上有, 所以就出車禍了
LAGG是客戶原本有,但原廠沒想到,所以這是原廠的鍋
車行剛好有LAGG的車子,但是也沒想到是這問題,只想釘
原廠,就變事故了。
而且這LAGG應該也是車行裝的? 那要怎麼究責呢?
別忘記B有拿到原廠的回覆信,而且最終也只有輪胎廠能修
復這問題,輪胎師父能做的就是被客人罵而已
等等 LAGG 什麼時時候變成車行裝的
好修正一下 LAGG不知道怎麼來的 我只是猜測是車行(B)裝的
LAGG是客戶環境標配,不在開發案本身裏。
但應該在開發前要調查清楚。
車行有沒有是未知的,只是客戶有且裝了穩定出bug
但B有踩到LAGG, 所以我是猜LAGG是公司做的功能
時間上LAGG是亡羊補牢發現,或者發覺到上新code還是錯的
至於誰有誰沒有,兩邊互推串資源義務無益釐清事實
LAGG -> Link Aggregation? 所以是在講NAS喔 XD
1.是,但不是只有NAS會用。
若是分享器更新完弄壞資料, 廠商會跑來救資料也是很神奇
後來發現LAGG會造成問題的不是車行是原廠,車行的環境在
客戶炸了之後原廠拿去測也無法復現,最後原廠才知道師父
在測到問題前一天做過網路測試所以有LAGG
是啊 不知道LAGG是什麼也可以討論客戶車上有LAGG、LAGG是
不是原廠,討論半天..
在有LAGG的環境會炸掉A的能力就是很弱,不知道有什麼好
說,原原Po還想要講A是RD不想讓他揹這個bug的責任
我寫一個database driver給你用,在cluster環境會把資料
炸掉,但是我只有在單機環境測過都沒問題啊,一定是你環
境有問題,看誰聽得下去
「誰叫你們不說你們有用到cluster,沒說是要我通靈解bug
?」A就這態度
原PO有提到LAGG技術有不照原本順序的特性
所以車行原本是編號順序裝螺絲, 結果用了LAGG技術導致
導致螺絲裝錯位置, 所以輪胎就脫落了 XD
照樓上說法公司該去跟客戶說你們搞砸環境啊…
不是好嗎你在亂比喻什麼
沒有給A LAGG環境是原PO的錯, A應該只是照需求做
就事論事如果你想要比喻就拿完全可類比的範例,不要已經
是不可類比的領域還硬要繼續用這個範例
不好意思 讓你困惑了 哈哈哈
我覺得B講那些話只是意氣用事,他肯定沒有能力repro
如果能的話以B個性不可能不嘴一頓A/QA,然後公司面究責
要以local UT的狀況當依據更是沒道理,你不能因為一個人
講話機歪就說他責任最大,我還是傾向與其看一個人說了
什麼,不如看他做了什麼,事實就是B已經做了他職責內能
做的所有事,但A以及QA都沒有把他當一回事
我認為B不該沒驗證通過就把功能啟用 that's all
樓上,同理,那QA的職責呢?
QA失能 應該整組換掉 -> 後來看原PO說QA是老闆的人 XD
現在是B沒過QA卻過了?結果是整個開發流程有問題,這樣
還算不算B的問題?
這部分就我說的,A認為B環境不可信,所以B以QA結果當驗
證你也不能說他故意搞事
事實上B測第二次爆第二次也只會被A說你就環境有問題
QA過了 就扯到原PO了 沒提LAGG環境
阿如果他堅持不啟用,理由是我的local沒測過,然後delay
客戶不爽跑掉,是不是又要說B責任最大
應該要檢討的是CICD有沒有跑UT,跑integration test
你我看法不同 如此而已
我就說當下A部門怎樣都贏,但在客戶那裡炸了還回來找B究
責真是可怕…
現在講都事後諸葛,回到release前看,QA測沒事,A測沒事
CICD(不知道有沒有)有過,就B的local有問題,那怎算?
w0說的並沒發生 因為往不同方向發展了 是要討論別的案子嗎
就B原本是救世主, 但不知為何後來裝沒看到, 微笑插刀
w0說的就是原原PO描述的release前的事實啊
A部門一開始真把B當救世主就不會在客戶那裡炸了
不要人當初都被你們殺了,事後需要時再來封聖好嗎
我是指w0講delay客戶跑掉那段
B的local沒測過就是把環境和repro證明錄下來證明就好了
只要有人環境沒測過就是要找環境或code哪有問題
你能復現就不會是你問題,現在是B除了一開始說有問題後
就不管了,也不提供驗證方法,最後也不複測。
不然就是你復現不了,那也不會有你責任。
檢討B根本沒用 來個CDEF還不是一樣 該討論的是怎麼擋
好啦 就讓B被火 然後CDEF還是一樣 你天天都在管人而已
每天問底下所有員工是不是有不爽就好啦 事情都不用做
就算客戶沒跑,feature因為一個RD自己也無法重現的local
test fail而delay,你覺得他不會被HL更嚴重?
B堅持不開feature,大家就覺得在無理取鬧而已,根本沒用
講真的 主管只是遷怒B而已 有問題的是A跟QA
他是指環境如果錯了100%復現 環境對了0%復現
他也只測一次就肯定問題還是有 不然也不用說要
highlight什麼
很多人會把B說詞往亂講話的方向解讀 可是沒有足夠的
證據 都是各位的自由心證
要明說客戶是錯的就直說唄,不用繞圈子講
明白表示客戶用錯,所以資料蒸發了也是客戶要take care
這事件誰去責怪客戶? 不要打迷糊仗 認為B有問題不代
表認為客戶有問題 兩個綁在一起是在詭辯是嗎?
B的問題不是他的環境,是他自己own的程式爆了還放過的
作為。
B這種心態也有人挺,真的笑死。
整個團隊就是各個組自己爽,沒人敢跨部門要,職場這樣
正常啦
大家有發現我們知道的B,只是由他人轉述來的
不好意思 關鍵就在他「直接講要highrlight這問題」
你管不到別人家的東西測不出來 就要裝無辜裝死到底OK?
這一點人情世故都不懂
爆
首Po講一個我在科技業遇到的鬼故事 這件事主要發生在兩個人身上: A:是我同部門的同事,主要開發kernel層以下的功能。 B:是隔壁整合部門的同事,主要是開始kernel層以上的功能。 有一天A開發了某一個功能,B整合完之後發現會導致資料損毀。於是B發了一個bug給A,13
難怪IC house要推當責Accountablity 提到的每個人都幾乎有責任啦 就跟空難和起司理論一樣 不是只有一個單純的原因造成 Product owner每天或每周都應該了解進度/severity72
這篇文最鬼的明明就是原PO,這個Feature在他的組開發然後有問題,自己組的人+QA竟然 測不出來,結果隔壁組的人竟然有權限把Feature打開,B就算說原本就知道有問題硬要搞 最後補一句「有可能是我自己環境有問題」也是能全身而退 說到底身為新Feature的lead管產品品質+QA都管不好,有問題的code還能進到release br anch,最後還能PO出來讓大家評論B,這才是我看過最鬼的鬼故事吧78
我是原po,我來交代一些細節,供大家參考一下。 角色: 我在這裡的角色是application owner,我要推一個應用給客戶去使用。 我這個application需要多個feature來組成,B是我其中一個feature owner。 B這個feature需要多個kernel function整合才有辦法達成,當然B自己也要寫不少code。8
→ pokkys: 所以B根本不需要講他是故意的話。 07/25 19:37 所以大部分的人都搞錯重點了 因為事情對或錯往往都不是重點 而是看哪個部門比較大聲 B大也可以裝傻 退一步假裝真的是當時誤以為自己搞砸環境4
不是mindset也不是制度問題吧 是你們所有人的環境為什麼都跟客戶不一樣? B只有一開始的環境類似於客戶 後來也不一樣了所以可能也做不出來 環境不一樣25
再回一篇,先說我不是B但是這個細節出了更明顯不是B的問題了啊 這個Bug本來就是一個corner case只是好巧不巧在B開發的時候遇到一次,要是今天B剛好 就沒遇到這個Bug,你們還不是一樣照常Release,客戶一樣爆掉,這樣B不就剛好衰幫你 發現Bug而已? 你硬要說B的態度有問題,他也只是表達出他遇過且在你們根本沒修的情況本來就很可能8
到這邊為止 A看起來有把問題反應給你 你的工作應該是跟B的主管協調,看能不能讓B優先處理這個issue吧 大部分職場都會把開發需求區分piority 如果這是個嚴重的issue, piority設高並且必須優先處理.24
第一篇文章推文: pokkys: 我的職位要扛feature成敗,所以我也因此卡到升遷。 pokkys: 沒有火B這件事我也是傻眼+不滿,所以我比B還早離職 XD 第二篇文章內文: 其他人的部分,我是極力不想對A究責,B的主管也是一樣的態度。最後我們兩個送上去給老闆的說法是這兩個人的責任,10分裡只有1分。
94
[花邊] 馬刺隊在樂透抽籤過後已售出2000組季票According to the Spurs ticket office, deposits for new season tickets began rolling in "minutes" after the draft lottery announcement last night. There were 2,000 new season ticket packages ordered within the first 12 hours following the announcement.34
Re: [討論] 熱心或撈過界奇怪怎麼當到二級主管了感覺素質很差啊= = ※ 引述《zaku (....)》之銘言 : 部門內有一個好學的同事, : 興趣是跨足其他人負責的,較熱門的領域,看不懂的地方問owner態度也還不錯。 : 但最近有某同事有被惹毛了,原owner在不知情的狀況下被他抓到一個bug,14
Re: [討論] 新人問哪些問題會覺得他很專業認真回一下 Shared folder在哪?有共同編輯的wiki page嗎?有build code流程頁面嗎? 有用虛擬編譯環境嗎?是用docker 嗎? 我git push後是去哪裡開code review?有CICD嗎?有用gmock 寫unit test嗎?有做regression test嗎? Debug build command要怎麼下?有debug mode嗎?15
Re: [請益] 如何有效率的看code ?如果你沒寫錯的話 一年多看幾萬行code真的不多 我也是轉職仔,原本在ic house寫C做韌體,一個人負責一個.c/.h檔。一年才進三行code。 轉職後寫C++整個team大約十多人,負責的那一層有兩千萬行code。然後第一年就進快一萬行code。 我原本不會C++的,所以什麼framework,modern C++,design pattern,multithreaded 之類的都沒學過要重學。8
Re: [心得] 我在科技業遇到的鬼故事之一這問題蠻有趣的 我問了一個在微軟跟亞麻做過的業內人士 A關ticket本身有沒有問題 她回答: non-reproducable其實蠻常發生的,對方又不肯合作釐清問題,除了關ticket還能怎樣 處理過ticket就會知道,很多確實是開ticket的人自己搞崩,不在狀況內,內容寫得不清不9
[問題] lawson ticket app 電子票認證問題預計3月要參加的演唱會有抽到票了 是lawson ticket網站抽選的電子票 我的lawson ticket會員資料 住址跟電話是填日本朋友的其餘資料是填自己的 有買了1張Mobal日本sim卡5
[影音] fromis_9 - ‘9 WAY TICKET’ HIGHLIGHT MEDLEYfromis_9 The 2nd Single Album ‘9 WAY TICKET’ HIGHLIGHT MEDLEY --2
[北美] 軟韌體工程師工作型態(ownership與否)大家好。 是這樣的, 我從2009開始做embedded software以來經歷過三間公司, 每間公司在程式開發或維護上面一直都是沒有ownership的概念。 一直到去年換了新公司第一次接觸到ownership的工作型態。