Re: [请益] n万行的code

楼主: calgari (Cal)   2016-07-15 14:43:36
※ 引述《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多的那些模组, 自然会让你有非常多机会看细节阿~~~
作者: phoebe9256 (肥比冰心)   2016-07-15 15:30:00
作者: xvid (DivX)   2016-07-15 15:39:00
看的出框架和流程是种幸福
作者: antiall (Hammer Smashed Face)   2016-07-15 16:07:00
5.1M行...
作者: Ommm5566 (56天團)   2016-07-15 16:31:00
5m也还好 刚刚cloc一下linux kernel 4.5m只是新东西要3个月trace完还蛮难的.......
作者: bab7171   2016-07-15 17:08:00
不是都看函式索引吗。这样其实code也没那么多
作者: Hikkiaholic (= =a)   2016-07-15 17:21:00
5m还好咧 linux kernal你写的喔?
作者: Ommm5566 (56天團)   2016-07-15 17:30:00
我只是提供一个比较值 linux系统复杂度接近5mwin的函式库有时候几十万行就很难读 真的是架构问题
作者: iceberg (((You only live once)))   2016-07-15 20:24:00
推这篇,但有框架跟flow看的话,真的是太幸福惹
作者: mos888tw (none)   2016-07-15 20:36:00
借问一下5.1Meg行 complie要多久?
作者: alarm911 (Burrerry Summer)   2016-07-16 00:24:00
很好奇你trace什么程式trace到5.1M, 不过看code的确就是看原理和流程
作者: sayya2311 (ya)   2016-07-16 10:03:00
屌的不是觉得5m行还好,而是觉得linux kernel还好...台湾软件靠你们了...
作者: Ommm5566 (56天團)   2016-07-16 12:09:00
我只是提供benchmark 不是在呛人.....
作者: mytelson (此ID的L是一,非正牌)   2016-07-16 12:28:00
比kernel还多 会还好而已吗
作者: Ommm5566 (56天團)   2016-07-16 15:35:00
对不起我用字错误 把还好删掉改很猛
作者: ericwan (万修)   2016-07-16 22:39:00
什么code可以写到5M ...linux kernel核心不过几万行...问题是全世界没有几个人完全懂所有部分都是subsystem maintainer 在帮忙维护...会些出5M的code...台湾软件靠你们了...
作者: keyut2433 (keyut2433)   2016-07-17 04:52:00
哇赛...讲的这么轻松我真的要用跪的看这版了

Links booklink

Contact Us: admin [ a t ] ucptt.com