※ 引述《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 的协同开发,彼此成长成似乎是免付费的高手.别人若都看不懂是要如何加入合作?透过网络如何紧密合作?对发展中的软件若不是架构与构想良好,高手怎肯投入?好的量测评估工具,甚至协助除错的工具因之被导入,协助分析流程的工具也随高手的加入而带进来.展示出有潜力的专案自然会有金主进来投资.此时, 就是不给改的(受封锁保护的)就投资付费造平台工具找高手造新工具另从他途突破.