💎一站式轻松地调用各大LLM模型接口,支持GPT4、智谱、星火、月之暗面及文生图 广告
### 重构工具的技术标准(Technical Criteria ) 重构工具最主要的用途就是让程序员可以不必重新测试,便能对代码进行重构。即使有了自动化测试工具,测试仍然是很费时间的,如果能完全避免测试,将可极大加快重构过程。本小节简短讨论重构工具的技术标准。惟有满足这些标准,重构工 具才能在「保持程序行为」的前提下,对程序进行改造。 **程序数据库(Program Database)** 对于重构工具,最早被人们所认识的需求就是「贯穿整个程序,搜索各种程序元素」的能力。例如,对于某个特定函数,找出其所有可能被调用点;对于某个特定的instance 变量(译注:non-static 变量),找到读/写该变量的所有函数。在Smalltalk 这样紧密集成的环境中,这类信息总是被维护为一种便于搜索的格式。这不是传统意义上的数据库,但的确是一个可搜索的数据库。程序员只需执行一次搜索动作,就可以找到任何程序元索的交叉引用(cross references)。这种能力主要源自代码的动态编译机制:当任何一个class 被修改,就立刻被编译为bytescodes,而上述的「数据库」则同时得到更新。在较为静态的开发环境如Java 中,程序员是把代码输入到文本文件中;这种环境下如果要更新程序数据库,就必须运行一个程序来处理这些文本文件,从中提炼相关信息。这样的更新过程和Java 代码自身的编译过程很相似。一些比较先进'的开发环境(例如IBM VisualAge for Java)则模仿了Smalltalk 的程序数据库动态更新机制。 有一种原始(粗糙)的作法是:以诸如grep 之类的文本处理工具来进行搜索。这种 办法很快就归于失败,因为它无法区分名为foo 的变量和名为foo 的函数。要建立程序数据库,就必须借助语义分祈来判断程序中每个语汇单元(token)在语句中的地位。而且这种分析在定义和函数定义两层面上都不可少:在class 定义层面 上,需要以语义分析(semantic ana)来区分instance 变量和函数;在函数定义层面上,需要以语义分析来区分instance 变量和函数引用(method references)。 **解析树(Parse Trees)** 绝大多数重构都必须处理函数层面下的一部分系统,通常是对「被修改之程序元素」的引用。举个例子,如果某个instance 变量被改名,那么该class 及其subclass 对于该instance 变量的所有引用都必须更新。有些重构手法则整个运作于函数层面 下,例如将某个函数的一部分提炼为一个独立函数。由于对函数的任何修改都必须能够处理函数结构,因此我们需要parse trees(解析树)的帮助。这是一种数据结构,可用以表现函数的内部结构。下面是个简单例子: public void hello( ){ System.out.println("Hello World"); } 这个函数相应的parse trees(解析树)如图14.1。 ![](https://box.kancloud.cn/2016-08-15_57b1b5e9b3229.gif) 图14.1 hello() 函数的解析树(parse trees) **准确性(Accuracy)** 由工具实现的重构,必须合理保持程序原有行为。当然,完全的行为保持是不可能达到的,重构总是会给程序带来一些细微改变。例如重构可能会对程序的运行速度带来数个微秒的变化,这算是「完全的行为保持」吗?通常这般微小差异不会对程序造成影晌;但如果程序有严格的实时性要求(real-time constraints),这一点点差异就可能导致整个程序出错。 即使是传统程序(而非实时系统)也可能被重构破坏。假设你的程序建构了一个字符串,然后使用Java Reflection API 执行以这个字符串命名的函数,那么如果日后你修改这个函数的名称,程序就会抛出一个异常;重构前的程序不会这样做。 然而,对绝大多数程序来说,重构可以相当准确。只要「可能破坏重构准确性」的因素都被识别出来,重构技术员就可以避免在不适当时候进行重构,也可以避免对于「重构工具无法修补的程序」错误地进行手工修补。