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,充其量是简单逻辑规则的判断,完全采用程序逻辑的方式实现。