打造第二代测试框架TestDriven 2.0（四）—— 代码对象化建模技术
------------------
前言 Preface
------------------
本文是第二代测试框架系列文章，同时也是软件工程革命三部曲中的技术文献。
本文从Visual Studio的重构出发，分析可行的代码对象建模技术，此技术是TestDriven 2.0 的核心技术。
------------------
代码对象化建模
------------------
使用Visual Studio，或者Eclipse的用户，一定非常依赖：查看此方法被引用的列表。
有时候我们写着写着代码，总是中途需要查询，这个时候任何IDE都会进入常常的等待时期，这个过程需要对代码（C#, Java） 进行词法分析，从静态分析代码调用情况（当然会使用部分动态反射获取周边DLL等，这个视IDE如何实现了）。
正是一个这么重要的功能，到目前位置，我踏遍了整个互联网，仍没有发现有个人去做代码对象化建模，让代码关系持久化。如果实现了这个功能，我就可以至少实现以下一个目标：
对比2个版本的类，查看这个类的代码变动产生影响范围。
一旦这个需求被实现了，我就能很快的进入代码半自动化辅助编程了，甚至比大部分公司的软件开发过程领先一个身位。比如
1. 需求变更的时候，针对需要修改的类，评估影响范围。
2. 代码完成后，自动进入回归测试。
3. 自动生成代码文档归档。
。。。。
今天我就介绍下我目前的研究进展。先看看截图：
主界面设计，我参考了Google的风格，非常简单。
输入查询关键字之后，列举出所有相关的代码片段。
点击不同的区域，进入不同的明细，包括了程序集、类、方法。
在这里，可以清楚的看到这个方法的声明；调用了什么方法；被什么方法调用。
------------------
架构设计
------------------
上面只是简单的演示了一个基于网站的查询功能。更强大的功能是本地的应用。依据网站的代码对象数据库，本地能够方便的查询各种代码关系，然后进一步处理。
要实现这个功能浪费了我差不多10天时间。最大的障碍在性能方面，因此代码模型需要细化到什么程度？本地如何缓存？代码差异比对如何提高性能等问题。这里一一解析。
首先是对象设计，.net提供了很漂亮的自描述对象TYPE，但是他实在太冗余了，因此我需要瘦身，得到：
ApiAssembly 程序集对象
- AssemblyName
- AssemblyApid
- Classes //类
- AssemblyReferences //程序集的依赖关系
ApiClass 类对象，这里包括了接口、类、枚举、代理等等。
- ClassName
- ClassApid
- AssemblyName
- AssemblyApid
- Methods //类方法
- Inheritances //类继承关系
ApiMethod 方法对象，包括了Index, Property, Method等
- MethodName
- MethodApid
- AssemblyName
- AssemblyApid
- ClassName
- ClassApid
- Parameters //输入参数
- References //方法引用其他方法列表
ApiReference 依赖关系
ReferenceApid
ReferAssemblyApid,
ReferClassApid,
ReferMethodApid
在这个对象设计中，最核心的是xxxApid这个字段，为了提高整个系统的性能，我们不可能查询、比对的时候一个个对名字、参数、是否范型、范型类型等等去枚举比对，因此我通过Apid字段，对每个类进行一个唯一的MD5操作，这样日后比对的时候，只要查询这个APID值就能够迅速获取类之间的关联关系。这个是整个核心设计关键一环。
例如某个类 public class Hello<string>
我对这个类的 MD5 ( 名字+是否范型+每个范型参数的类型)，计算得到了一个字符串。这样只要符合这个字符串，就代表这个类。
其次，是本地缓存设计，本地使用XML进行代码关系缓存。这个XML可以直接从网站下载，之后和本地项目代码同步。缓存使用分片设计，不同的项目使用不同的xml文件保存，系统运行的时候延迟加载，这样就能够提高整体性能。
最后， 使用了IL，获取这个方法调用了其他方法的声明，这样就能够建立关联关系。
------------------
后记
------------------
TestDriven 2.0 的核心思想是——代码之间是有关联的。我们应该充分利用这个关联关系，去提高我们的生产力。以往的静态文本比对、SVN代码归档等 1.0 技术已经过时了，在 web2.0 的时代，我们也需要进化了。
本文已经建立了一个代码关联数据库，将来任何的 2.0 操作都将基于这个数据库。 个人感觉，是自己划时代的一次进步。 下一篇文章将直至核心，论述 基于 代码关联数据库的 测试驱动。
