调试胜于逆向分析

 

debug, instead of reverse-engineering

 

转入CDT阶段了

 

还是一步一步来吧！

 

从CDT入手，柳暗花明，找到了codan这个极好的切入点——这是CDT尚未发布的插件包，在dev.eclipse.org的CVS上可以找到。

 

BTW：找CVS就找了半天，实在是相当粗心啊！还去找什么release engineering，太复杂，直接在eclipse Build / Export就足够完成插件开发的基本步骤了！当然，这样一来，在版本上就只能选择当前已经发布的版本而不是CVS里面最新的版本。

 

codan这个插件其实隐藏在CDT官方主页的Static Analysis一则文档中。为了找C的analysis，在eclipse plugin Center上找了半天，效果不好，还是回归到CDT上自己开发吧！后来一想，其实是不太好找——比如checkstyle这样的好东西就没有显示。

 

一旦准备自己开发，看到大量CDT代码就需要工具，于是又翻出来eUML2来做UML逆向，才发现自己最需要的实例之间的引用关系竟然没有做进去！所谓的引用关系仅限于一个包而已！又经过Enterprise Architect ，MDG，MaintainJ的失败后才幡然醒悟：干嘛要从运行时生成UML图？直接跟踪运行过程不就很清楚类之间的关系！！

 

PS：跟踪，debug，是对付复杂的Java类层次的有力办法，最为简单有效。

 

跟踪之前，当然要有tests包，codan的tests包是依赖于cdt.core.tests的，而这个包发布时没带源代码！而且发布的包导入后根本无法执行测试！以为脚本有错，后来直接把class目录拿过去开始执行codan.tests，终于跑起来了。

 

于是跟踪，debug，对于codan的结构越来越清晰。

 

 

PS：发现很多开源的Java项目，类层次确实相当冗余——当然，开发者早期考虑不可能非常准确周全。所以，跟踪，相比逆向，是非常实用的经验。

 

了解大概后，将其按照自己的架构重构了一遍，保留checker的扩展点，UI合并为一个，将模型也调整了，不需要那么多IChecker，AbstractAstChecker。既然这个插件的主体功能就是checker，就先不考虑其它扩展。checker本质是算法，要什么数据找eclipse.resources、cdt.core.dom.ast要就行了，因此删了很多东西。

 

PS: 基于中间件的开发，一定要清楚自己要做的东西本质是什么，只做这部分，其它以后好说。

 

完成基于AST的checker后，下一步是做语法扩展。这是个体力活，但也是个值钱的活，做一个，有点特色就行了，初步定为CVI，备选C51。选C51是因为简单，而且有实例，CVI要实用，还需要做一些更加复杂、有创新难度的活，暂且放过。在这个上面做AST checker，充其量是简单逻辑规则的判断，完全采用程序逻辑的方式实现。