在Chapter 7, 多模块企业级项目中，我们展示了很多Maven POM文件结合起来生成一个功能齐全的多模块构建。虽然那一章的样例想要表现一个真实的应用——与数据库交互，与web服务交互，本身又暴露两个接口：一个web应用，还有一个命令行；但这毕竟是我们杜撰出来的样例。要表现一个真实项目的复杂度可远远超出了你正阅读的本书的能力范围。真实生活中的项目往往经历了很多年的发展，由很多关注点不同的不同组的开发者维护。现实项目中，你通常会评价由其它人所做的决定或者设计。本章，我们回头看一下Part I, “Maven实战”中的样例，问问我们自己，基于我们对Maven的了解，能否对该样例做更合理的优化。Maven很强大，能根据你的需要变得很简单或者很复杂。因此，通常完成同样一个任务有很多种方法，而且通常没有一个“最正确”的方式来配置你的Maven项目。
别误解最后一句话，认为它批准你可以要求Maven做一些本非它设计目的的事情。虽然Maven允许多样的方式，但当然也有“一种Maven的方式”，如此使用Maven你将能够有更高的生产效率，因为Maven本身就是被设计成这么用的。本章要做的就是传达一些能在已有项目上进行的优化手段。为什么我们不在一开始就介绍一个优化的POM呢？为教育而设计的POM与为了效率而设计的POM有着不同的需求。虽然在你的~/.m2/settings.xml中定义一些设置比在pom.xml中声明一个profile简单得多，但写书及读书主要的还是一步一步来，确保没有在你没准备的好情况下就介绍新的概念。在Part I, “Maven实战”中，我们也花力气避免让太多的信息淹没读者，这样，我们就跳过了一些很重要的概念，如将在本章介绍的dependencyManagement。
在Part I, “Maven实战”中有一些例子，本书的作者通过捷径掩盖了一些重要的细节，以带你关注那些特定章节的重点。你学习了如何创建一个Maven项目，不用去辛苦的读完几百页的所有原理介绍，就能编译并安装它。这么做是因为我们相信对于新的Maven用户来说，快速的呈现结果比在一个持续过长的故事中迂回更重要。在你开始使用Maven之后，你应该知道如何分析项目和的POM。本章，我们回头看看Chapter 7, 多模块企业级项目中所留下的样例。
