这个冗长的目标（相信我，我还见过冗长得多的目标）要执行四个不同的过程：编译源代码、编译测试、运行 JUnit 测试和创建一个 JUnitReport。要担负的责任已经够多了，更不用说将所有 XML 放在一个地方所增加的相关的复杂性。实际上，这个目标可以拆分成四个不同的、逻辑上的目标，如清单 4 所示：

　　清单 4. 提取目标

<target name="compile-src">
　　<mkdir dir="${classes.dir}"/>
　　<javac destdir="${classes.dir}" debug="true">
　　　<src path="${src.dir}" />
　　　<classpath refid="project.class.path"/>
　　</javac>
　</target>
　
　<target name="compile-tests">
　　<mkdir dir="${classes.dir}"/>
　　<javac destdir="${classes.dir}" debug="true">
　　　<src path="${test.unit.dir}"/>
　　　<classpath refid="test.class.path"/>
　　</javac>
　</target>
　<target name="run-tests" depends="compile-src，compile-tests">
　　<mkdir dir="${logs.junit.dir}" />
　　<junit fork="yes" haltonfailure="true" dir="${basedir}" printsummary="yes">
　　　<classpath refid="test.class.path" />
　　　<classpath refid="project.class.path"/>
　　　<formatter type="plain" usefile="true" />
　　　<formatter type="xml" usefile="true" />
　　　<batchtest fork="yes" todir="${logs.junit.dir}">
　　　　<fileset dir="${test.unit.dir}">
　　　　　<patternset refid="test.sources.pattern"/>
　　　　</fileset>
　　　</batchtest>
　　</junit>　　
　</target>
　<target name="run-test-report" depends="compile-src，compile-tests，run-tests">
　　　<mkdir dir="${reports.junit.dir}" />
　　　<junitreport todir="${reports.junit.dir}">
　　　<fileset dir="${logs.junit.dir}">
　　　　<include name="TEST-*.xml" />
　　　　<include name="TEST-*.txt" />
　　　</fileset>
　　　<report format="frames" todir="${reports.junit.dir}" />
　　</junitreport>
　</target>

　　可以看到，由于每个目标只担负一种责任，清单 4 中的代码理解起来要容易得多。根据用途分离目标，不但可以减少复杂性，还为在不同上下文中使用目标创造了条件，必要时还可以重用。

　　庞大的构建文件也有一种很重的气味

　　Fowler 还将 庞大的类也看作一种代码气味。构建脚本而言，有这种类似气味的是庞大的构建文件，它相当难以读懂。很难知道哪个目标是做什么的，目标的依赖关系是什么。这同样会给维护带来问题。而且，庞大的构建文件通常有相当多的剪切-粘贴的痕迹。

　　为了缩小构建文件，可以从脚本中找出逻辑上相关的部分，将它们提取到更小的构建文件中，由主构建文件来执行这些较小的构建文件（例如，在 Ant 中，可以使用 ant 任务调用其他构建文件）。

　　通常，我喜欢根据核心功能拆分构建脚本，确保它们可以作为独立脚本来执行（想想构建组件化）。例如，在我的 Ant 构建中，我喜欢定义四种类型的开发者测试：单元、组件、系统和功能。而且，我还喜欢运行四种类型的自动检查工具：编码标准、依赖性分析、代码覆盖范围和代码复杂度。我不是将这些测试和检查工具的执行放在一个庞大的构建脚本中（还加上编译、数据库集成和部署），而是将测试和检查工具的执行目标提取到两个不同的构建文件中，如图 2 所示：

图 2. 提取构建文件

　　更小、更简洁的构建文件维护和理解起来要容易得多。实际上，这种模式对于代码而言同样适用。我们似乎在这里看到了模式的概念，不是吗？