关於Trace Code，可以30分钟搞定的就不讨论了。 我的运气比较好，程式语言是Java，很好分析，以下讨论Java的作法。 像是Eclipse JDT的AST架构、Tomcat Source这种级别的，请考虑用XMind去作笔记。 树状结构在描述堆叠还是程式码之间的呼叫很方便，当然如果有钱可以用那种 专门分析的软体那是最好，不过通常没有那种钱就是了。 其他一般小的没有Container观念的东西，用笔记本还是Notepad++就够了。 如果不是一天可以看完的，我个人的理想作法会是： 1. 先丢到SVN里，确保可以管理，然後想办法正确执行这只程式。 2. 建立所有这只程式应该要通过的功能列表，并至少执行过正确的逻辑流程一遍。 3. 依据每个功能执行流程，抓出程式进入点，建决策树。 (分支太多就用XMind，少一点就用纸笔就好，搞啥Visio的只是找自己麻烦。) 4. 观察所有的功能流程里参与的角色Class有哪些，然後很不幸的God Object就会 在这时候跑出来了。 5. 观察角色Instance的生命周期，特别如果是有Container、Multithread、Persistance Layer、Request-Response、Event这类东西的时候事情得要很小心，这有点像是在 玩SUDOKU，你的脑袋得在多个构面、维度去了解程式码对整体系统会产生的影响。 6. 观察角色Class的方法列表，从名称、资料结构去分析物件的责任。 7. 呈上，你得小心角色Class的资料结构在各种不同的构面观察到的状态转换。 (如果你像我一样运气好或不好，你会在这个阶段挖到一堆潜在危机。) 对够复杂的资料结构(通常是系统的关键点)请记得善用IDE Break Point的功能， 你应该要能够预测Programming Stack里每个参数在不同的状态转换时应该呈现的值 ，才表示你确实了解的够透彻。 8. 快速的做假设、建立模型、验证，然後修正。 重点是，halting problem。 请根据你的目标来决定你要挖到什麽程度，不要明明只需要一口井，结果挖了个 小叮当地底王国还是什麽考古学遗迹出来。 这种看Code的事情如果有幸多做几次： 1. 你会真的很痛恨God Object。 SUDOKU只有9X9还不错玩，nXn就很糟糕了。 2. 你也会很痛恨Over Design。 明明做的事情就是那一件，这个东西的Scope了不起就是个卖菜的，不会去卖飞机 还是大炮什麽鬼，干麽找自己麻烦？最讨厌的是，『预留』的东西到了时候其实 还是得打掉重盖，徒增麻烦。 3. 伪OO比伪娘更该死。 (WTF! You idiXX Mother XXcker!) 4. 你对原作者的脑神经虚拟路径结构有了新的体认。 写程式是有风格的，同一个人的程式看得久，你就会看出一些那个人偏好的东西 出来。 5. 你会很心虚。 靠，到底自己小时候造了多少孽阿？如果当初写得那些鬼有人这样翻...(羞) (Shame on me...) 6. 你会相信Code Review 跟Pair Programming 是值得的东西。 一个是宁可要爆现在爆，不要一年後才来断简残篇、郭公夏五，一个是挨骂找个 垫背的。 7. 你会变强。 当然，这是Garbage in, Garbage out，请多看高品质程式码。 Java Std老少咸宜，Collections翻翻，配大学课本可以把资料结构演算法基础打实。 实务应用上可以看看Tomcat, Jetty or Eclipse，够大够凶而且复杂度够高。 想看聪明的人写的，可以考虑google java collections。 -- 我所信仰的科学是一种谦卑的理性，承认自身的无知与渺小才能观察到世界在我们贫 弱的知觉上留下来的痕迹。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 123.194.186.232