※ 引述《randomly (倫敦鐵橋垮下來)》之銘言：
: （幫以前同學代po）
: 背景：四大資工碩，役退。
: 同學最近才剛工作兩三個月
: 聽他說一進公司，主管直接丟了一份project的source code給他
: 原本負責這個project的前輩已經離職了，所以當時是由主管代職，
: 這份source code林林總總大概有6~7萬行
: 這麼龐大的code，當然也是埋一堆bug，通通直接workaround
: 來一個打一個，來十個打十個
: 主管表示：試用期過後，這份code之後就交給你maintain了
: 所以他從第一天進公司開始每天都在看code
: 三個月也一轉眼過去了，
: 剛剛吃飯聽他說，上禮拜開會主管突然問他
: 「某case發生時會有bug，請問是在哪個function什麼原因造成的?」
: 同學自己也不熟，只好回說待會回去看一下再跟主管回報
: 主管只丟了一句話就離開了：
: 「你前三個月試用期都在幹嘛？
: 才問一個case也答不出來，之後你是要怎麼開發，怎麼maintain?」
: 各位認為這件事是我同學能力不足？ 還是主管太嚴苛？
除非在學時就常常把玩 open source，上 github 幫忙解 issue，
不然第一次就追幾萬行，除非你天生神力，不然一定覺得很吃力
我第一次碰上這種工作是 12 年前，那份 code 不只 6-7 萬行，
起碼 40 萬行以上，用當時最新的電腦完整編譯一次大概要 20 分鐘，
我大概看了一年，每星期我要都把看懂的部份寫成文件給主管 review。
那時候笨笨的，只會用 grep 來看原始碼，然後用 word/ppt 很辛苦
的把 call graph、資料結構、繼承階層畫出來，那時候認識了一位高手
，他說要把 data flow 找出來，這對我幫助很大。
大概是因為我是爛私大畢業，薪水又低，所以老闆可以
忍受我一年吧XD
那時候也沒有人跟我講要用 vim+ctags+cscope or SourceInsight，
或是用 doxygen 產生 call graph，白走很多冤旺路，如果是現在
還可以用 valgrind 在 Run-time 時產生 call graph，比起當初，
現在可以用的工具很多了。
如果是現在的我，還會設法用 profiling 工具找出最常被執行的區塊，
按照80/20 法則，6萬行的程式只有約一萬行是最常被執行的，理解一萬行
應該要比理解 6 萬行容易許多。
所以我想你同學最大的問題是...他怎麼沒跟學長或板友求救?