推 phoebe9256: 推 07/15 15:30
推 xvid: 看的出框架和流程是種幸福 07/15 15:39
推 antiall: 5.1M行... 07/15 16:07
※ 引述《dakkk (我是牛我反芻)》之銘言：
: ※ 引述《randomly (倫敦鐵橋垮下來)》之銘言：
: : （幫以前同學代po）
: : 背景：四大資工碩，役退。
: : 同學最近才剛到某有名的代工廠工作兩三個月
: : 聽他說一進公司，主管直接丟了一份project的source code給他
: : 原本負責這個project的前輩已經離職了，所以當時是由主管代職，
: : 這份source code林林總總大概有6~7萬行
: : 這麼龐大的code，當然也是埋一堆bug，通通直接workaround
: : 來一個打一個，來十個打十個
: : 主管表示：試用期過後，這份code之後就交給你maintain了
: : 所以他從第一天進公司開始每天都在看code
: : 三個月也一轉眼過去了，
: : 剛剛吃飯聽他說，上禮拜開會主管突然問他
: : 「某case發生時會有bug，請問是在哪個function什麼原因造成的?」
: : 同學自己也不熟，只好回說待會回去看一下再跟主管回報
: : 主管只丟了一句話就離開了：
: : 「你前三個月試用期都在幹嘛？
: : 才問一個case也答不出來，之後你是要怎麼開發，怎麼maintain?」
: : 各位認為這件事是我同學能力不足？ 還是主管太嚴苛？
: 重點不是主管太嚴苛 或你同學能力不足
: 先說一般狀況 一個case有bug 很少說看code可以直接解的出來 如果是這樣 之前人ma
: intain個屁呀
: 所以一般情形 解bug要先複製 歸類後再來trace
: 但這件事很明顯主管幹的不是這個
: 現在情形是在開會 你回答不熟 主管輕易放過你 會對其他同仁有不好的示範效應 或是
: 這主管很好敷衍
: 所以 主管應該是覺得 聽到bug的情況 至少要聯想到大概什麼function有問題
: 例如畫面怪怪的 解就說回去trace看看顯示模組
: 不然就至少一個萬用的 怪給mcu
: 在開會上 最好不要回答 不知道 我不清楚
: 你隨便回答什function都ok
: 因為只有你有code說錯也不會有人知道
: 董？
是我我就不會像你這樣做,
因為:
1. 要是現場剛好有前任或現任owner在, 你這樣講擺明了是要把火弄到他頭上,
他不搞你搞誰?
(不過這個case看起來好像是一人maintain就是, 好像也不會有這問題?)
2. 主管聽了你的, 拿去報給客戶, 然後客戶急著有解,
就往那個方向去try有沒有workaround先改,
結果最後發現並不是, 那你不就自己挖了個自己也不知道的大坑給自己跳?
3. 如同你說的, 解問題要先複製, 那要是這問題根本就難以複製或根本就是複製不出來,
你隨便拿了個東西出來講可能是xxx的問題, 最後要怎麼打圓場?
小弟trace過最大scale的source code大約有5.1M行,
我也是三個月看, 怎麼看? 就先專看system arch.跟function flow阿!
細節等這些都熟了再說, 遇到問題見招拆招, 不然你哪來這麼多時間?
碰到這類問題我都是這樣回:
1. 如果我沒開始看這問題, 我就說我先跟test team確認複製手法跟發生率, 再來追
2. 如果我看了, 也複製的出, 但還沒時間看,
就把幾個會導到某個bug case的流程都拉進來講, 說這些都有機會, 需要時間查
這樣有幾個好處:
(1) 假設現場有相關owner,
現在這個問題你說你要查下去, 然後講了一堆flow,
這整個flow上有牽扯到的相關module owner自己當然心知肚明, 會豎起耳朵聽.
但你沒把module點出來, 火就不算燒到他頭上,
大家都不想要火燒到自己身上, 對吧?
現在有人要來看, 幹嘛不給他看?
萬一你解不出來, 也不會這麼快燒到owner, owner自己就有時間可以先看.
搞不好出手幫你一下還可以把credit變他自己的.
(這個case就要自己小心了)
(2) 你有機會可以爭取更多時間來看這個問題.
因為你熟悉流程的話, 一個問題出來, 你肯定會覺得某一條特別可疑,
你把其他相關度較低的給拉了進來, 其他相關owner多半也不會有意見,
因為整個流程一定會經過很多環節,
沒人能保證這些環節會不會影響到自己或別人,
大多數人肯定是會觀望.
那看這麼多環節需不需要時間? 當然需要阿!
這就是可以跟上面爭取更多時間的點了.
如果主管急著要解?
那他就會把上就把你點到名的環節中的所有owner全部拉進來一起幫你了阿,
issue是掛你身上, 你本來不知道可以找誰搬救兵,
這麼一來你就知道可以找誰了阿! 而且火還是沒有燒到相關人士的頭上.
(至少issue不是掛它們頭上, 壓力沒那麼大)
就算這些人不幫你, 至少你拿到名子了,
到code base上找這些帳號的commit history總行吧?
(3) 假設現場真的沒有人懂:
那你講出這一堆流程出來, 大家肯定只會覺得你超猛, 短時間怎麼看那麼多啊!
實際上對解bug有幫助嗎? 天知道, 搞不好完全沒幫助, 但至少氣勢先贏了!
那你就更有籌碼來爭取更多時間看這問題啦!
3. 如果這問題我看到一半, 還沒確定root cause, 那就把你走過的錯路給報上去,
說目前已經確認xx,oo,ox,...這些流程沒問題, 正在往其他方向查,
誰也不得罪, 也有個交代, 也不把話給說死給自己留退路, 豈不安全?
所以阿, 一開始看code, 別執著著學細節阿, 把框架跟流程搞懂比較重要,
誰有那麼多美國時間每個模組細節都k阿?
issue多的那些模組, 自然會讓你有非常多機會看細節阿~~~
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.219.195.149
※ 文章網址: https://www.ptt.cc/bbs/Tech_Job/M.1468565019.A.0D8.html