※ 引述《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 萬行容易許多。
所以我想你同學最大的問題是...他怎麼沒跟學長或板友求救?

除了cscope,ctags外glimpse cindex好像也不錯用

忘了提...記得用SSD,搜尋速度加倍啊~!!

SSD真的很重要!

這篇回文指出了工具的重要性.可以維護的就找免付費的高手來做.open source 的協同開發,彼此成長成似乎是免付費的高手.別人若都看不懂是要如何加入合作?透過網路如何緊密合作?對發展中的軟體若不是架構與構想良好,高手怎肯投入?好的量測評估工具,甚至協助除錯的工具因之被導入,協助分析流程的工具也隨高手的加入而帶進來.展示出有潛力的專案自然會有金主進來投資.此時, 就是不給改的(受封鎖保護的)就投資付費造平台工具找高手造新工具另從他途突破.