开始尝试使用Maven构建项目的时候，惊讶于只需要简单的几行xml就可以完成原来ant需要大量xml才能完成的工作。不得不说，人们在经过一定技术积累后，总能想到办法简化自己的工作。以前做项目，总是写Ant配置文件，满足于自己更灵活的配置，而没有去思考，这么做到底值不值得。
想象一下，如果我们每个人都满足于自己的私欲，为所欲为，我们的世界会乱成什么样子？在软件世界里，如果每个程序员都定义一套自己的规范，那么我们的软件会乱成什么样子？各个版本的浏览器就已经让众多程序员头痛不已了，更别提其他的了。想到这，你有没有感觉，其实java的成功，xml的成功，maven的成功都有其必然性，他们的设计理念都包含一个很简单但很深刻的道理，那就是“通用”。
为什么通用？因为遵循约定。
通用又会带来另一个好处，那就是学习成本低，当新人加入的时候，很容易上手，主要他了解约定，或者说规范就可以了。对比一下相同项目的ant脚本和maven脚本，也就是build.xml和pom.xml，你就会明白，我为什么说学习成本低了。如果没有约定，没有构建标准，n个项目可以能就要有n中项目目录结构，n种构建方式。
这种遵循约定写xml配置的方式就是最优的了吗？只能说是相对罢了。如果我们严格遵循约定，甚至可以省略掉xml的编写，因为xml可能会带来管理上的混乱。
众多javaweb的程序员一定都有编写ssh的xml配置文件的经历，而不知道你是否了解Rails。
Rails 的核心理念也是约定优于配置，这意味着在Rails中不会出现XML配置文件。Rails使用Web应用多年来积累的各种常见约定（更具体地说是命名规则）来代替XML配置文件，而在Rails内部的映射与发现机制根据这些约定可以实现对象之间的关联。
使用约定来代替XML配置文件说明Rails本身完成了大量的底层工作，这意味着使用更少的代码来实现应用程序是极有可能的。此外，代码量的缩减也减小了出现bug的可能性，降低了维护程序和升级程序的难度。
如果你有一种“强迫症”，发现程序员多少都有点强迫症，哈哈，就是不愿意遵循约定怎么办？我只能再写几句来试图说服你。你真的需要那么做吗？你真的需要那么个性吗？个性意味着什么？没有通用性。没有通用性意味着什么？死亡。你可能还会质疑，微软的很多东西都没有通用性，只能运行于windows平台，照样活得好好的。但你有没有想过全球那么多windows用户，windows的通用性是不可质疑的，间接使运行在它之上的软件拥有了一定的通用性。如果你还要再举苹果，好吧，朋友，你极端了。个性意味着复杂，没有人喜欢复杂的东西。
既然遵循约定那么有优势，是不是我们就该放弃配置，以约定为王？还得用maven和ant来说事。如果你目前的构建包含一些高度自定义的过程，或者你的项目结构不能轻易变更为maven规定的项目结构，或者你已经写了一些 Ant 脚本通过一种明确的方法完成一个明确的过程，而这种过程不适合 Maven 标准，你仍然可以使用ANT，或者将ANT脚本作为Maven的一个插件。从这个角度来看，约定不能干所有事情，总有一些是需要你自定义完成的。
综上，遵循约定虽然损失了一定的灵活性，但可以减少配置，降低复杂性，降低学习成本呢，使程序更优美。所以，我更倾向于约定优于配置。
