C# Code Analyser 及其它的开发背景

作了这么多年的代码编写，设计以及代码重构工作，发现其实我们有很大一部分时间（在我看来有50%以上的时间）是在维护代码（如果你是在做一个大系统的话）。维护代码本身包含了很多内容，其中最主要的两个是1）修改客户报告的bug；2）在现有的系统上满足客户提出的新需求。

应对代码的维护工作，我们有很多策略，例如，通过各种方式，采用各种文档来描述代码，使我们在对代码进行维护时，能够快速地找出解决方案。但是，实践证明，这种方式的效率很低，并且代价也会很高。当系统变得很庞大时，我们用文档来描述代码，并且要保持这种描述和代码执行的一致性，其成本有时会超过代码本身修改的成本。呵呵，说道这里，你可能觉得我说的有点过了。的确，我之前的那些所谓的阐述是建立在当我们仅仅只用文档的方式来管理代码时才可能出现。

我们的开发过程其实是这样的。

原始业务逻辑-->原始系统设计-->原始代码实现

而有没有人想过我们的维护过程又是怎样的呢？

变更业务逻辑-->变更系统设计-->变更代码实现

看上去很很简单，其实这个过程远比上面的描述要复杂得多。

首先，变更系统设计来至于原始系统设计+变更业务逻辑。我不知道我用+号将原始设计和变更业务逻辑连接起来是否严谨，但是我想说的是要获得变更系统设计，就必须对相关部分的原始系统设计有等同于原始系统设计刚刚定型时的那样的清楚的认识。这个过程是必须的，为了这个过程，有很多系统设计的大师发明了各种方法和各种工具来尽量帮助我们实现这一过程，使我们能够得到“有等同于原始系统设计刚刚定型时的那样的清楚的认识”。而这也就是为什么会经常有人说维护一个系统比开发一个系统还要困难的原因。

其实还有一份文档，常常被人们忽视作为管理的文档，但是使用的频率很高，那就是代码本身。当系统设计转换成代码实现时，系统设计就像一个完整的水晶被打碎成无数个颗粒洒落在地上。所以，要想从代码本身还原系统设计就如同要将洒落一地的水晶颗粒从新拼凑成一块完整水晶一样艰难。

所以，对于代码的维护，我们通常的做法是用文档管理代码中比较重要的部分（它的重要性完全有人来决定），其它时候通常还是去看代码，从代码分析出设计，再从设计分析出业务逻辑，然后再将变更后的业务逻辑考虑进来，然后得到一个新的设计，然后再得到一个新的代码实现，即以下过程

原始系统设计的部分文档+原始代码实现->原始系统设计->原始业务逻辑+变更业务逻辑->变更系统设计->变更代码实现。

就在这样的分析背景下，我想有必要开发一个从代码实现还原到代码设计的工具，至少可以帮助我们做到这一点，这就是Code Analyser。

 

开发历史

C# Code Analyser 开发感悟

Code Analyser 新算法测试通过

关于C# Code Analyser 的作用与下一步开发

C# Code Analyser 1.2.3发布

C# Code Analyser 1.2.1 发布

Code Analyser 1.1 发布

C# 代码分析器 1.0 版开发完成 

 

 

之前做的代码分析器其实还谈不上分析，其大部分分析工作建立在"查找"特征代码上，这也是为什么开发了这么几个版本后，最新的版本仍然存在bug的根本原因。最近发现了两个不错的资源，一个来至于PEG Lib，一个来至于Boost的Spirit框架。这些都在代码分析上走了很远，并且都很成功。

虽然已经有了成功的框架，但是我向我还是要将我自己的分析器写下去。毕竟要将分析器写出来，还需要掌握很多的技术，其中一个就是对递归函数的使用和MetaProgramming的使用，这两项技术都已经应用到了我目前正在开发的新版本中。

特别是对递归函数的使用让我觉得十分地有意义。最近在看《不完备性》原理，发现递归的意义远远不像我学计算机编程时想象的那么简单。这也是我冒着压力（因为已经有了很出色的分析器）继续写这个程序的原因。

 

 

更多内容请转到我的Blog导读