Maven3实战笔记16Maven总结

1.  前言

用了15篇Blog做Maven3的学习笔记，最后想想好像觉得总是比较冷冰冰的，将知识点列出来，停留在如何使用Maven的层面。那么咱们抛开书本，回过头来再看看哪些Maven的功能点，再来总结总结Maven到底为我们做了些什么，使用Maven的好处到底体现在哪里。

2.  Maven改变个人习惯

在没有Maven之前，我们开发一个新项目的时候，总是要引入很多第三方的组件为我们提供相应的服务功能，一般是以jar包的形式提供给我们。那么我们作为开发者一般都是比较关注直接依赖包，比如项目用到了xmemcached作为缓存客户端，而xmemcached组件（1.2.5本版本之前）要想正常使用，还依赖于该组件的同一个作者创建的slf4j组件。slf4j在咱们这个新建立的项目中就属于非直接依赖，间接依赖。在没有别人或者相关文档辅导的情况下，当拿到xmemcached包后是过程中报出了相关错误后才知道缺少了slf4j相关包，之后再打开Google搜索slf4j关键字，从而下载相关slf4j组件。很多时候我们都是这么做的。自从有了Maven后，开发人员其实只需要关注直接依赖就可以了，构建项目时候，Maven会根据组件自身的描述文件pom.xml自动去找寻该组件的依赖包，从而保证组件的正常使用。

而且项目还可以及时使用第三方的组件最新功能体现（稳定版本，非SNAPSHOT），第三方组件的最新版本发布后，Maven仓库会及时反映，下载到本地。

Maven倡导的是约定大于配置，Maven项目的源代码包位置、配置文件位置、测试用例代码位置都是有约定的。出现Maven之前，可能有一些项目，尤其是小项目，把配置文件、源代码、脚本一股脑全放在src下面，这样做其实呢，也不能说不对，就是给其他人看起来代码结构有点乱。Maven规定source code就放在src/main/java下面，配置文件就是放在src/main/resource，这样给人看起来比较清晰，不会给接手项目的人“一坨XX”的感觉。

打包方便，在项目前期，先将pom配置文件写好，之后根据配置文件的打包类型进行打包，这个功能实际上在EJB项目打ear包特别明显。当然了使用IDE，如Eclipse进行打包也麻烦不到哪儿去，只不过有些手工过程比较重复罢了。

3.  Maven改变团队

对于团队来说，Maven可以帮助团队内部、以及不同团队之间进行更好的沟通。团队内部可能进行着不同小模块的开发，但是小模块之间是有耦合、调用、依赖关系的，模块程序更新后，可以及时反映到内部Maven库中，团队内部有一个比较良好的及时构建和使用反馈。当然使用IDE配合SVN插件也可以做到，这种方式仍然是目前很多团队的项目构建方式，根据项目的规模，具体情况具体分析吧，有可能项目比较庞大，同一个团队的人还不在同一个地域，只能对外开放一个url，可以选择IDE配合SVN、也可以选择Maven配合SVN。这个时候可能Maven就比较有优势了，Maven构建的项目能够及时反映和自动下载、构建。

项目可以配合Hudson进行持续集成，持续测试，持续生成报告，持续反映项目的健康状况，持续反映团队状况。对于项目、公司、团队的队员工作情况都是比较清晰的，用数据说话，用邮件提醒驱动开发人员。个人认为，Maven确实能用这些数据反映项目、反映团队、反映队员的状况，也发挥了团队队员的主观能动性。从另一个层面来看，其实是Maven从敏捷开发中得到的其实吧。要求每个队员的水平也比较高，定期就得看看自己修改的部分在持续构建中有没有出问题，出问题立刻打起精神，找问题、解决问题，让项目更健壮。唉~~~资本主义就是要剥削劳动人民的剩余价值，从员工自身的观点来看这种比较紧张的工作气氛，到底是好是坏，短期也许还行，长期如此，精神上、心理压力、体力、精力是否能够承受，对于这个问题笔者觉得还是值得大家讨论的。但是有一点可以肯定，对公司发展、对项目交付、对客户的满意度，起到的作用绝对是积极的……

4.  Mavne改变项目

Maven项目都有特点，源代码、配置文件、单元测试文件夹一般都是按Maven规定，所以一般的Maven项目都比较好阅读，代码放置的位置比较清晰。项目打包后也可以安装到Maven库中，现在很多第三方的开源项目，尤其以Apache项目基本上都是符合Maven规范的。很多研究Apache组织下开源项目的朋友们拿到源代码后都是按照Maven标准去找寻原文件的。这样有一个统一的规范，比如自己开发个小组件，别人阅读起来也能从容入手。基本上从网上下载的第三方开源jar组件，打开META-INF文件夹下都有一个maven文件夹，里面就是该开源项目的Maven描述文件pom.xml和pom.properties。

Maven还能生成项目静态站点，该站点风格有点像wiki。该站点既包含了项目的一些基本信息，例如项目介绍、项目成员介绍、项目信息的链接，还能利用Maven插件生成一些报告数据，如测试覆盖率、代码提交情况等等，这样反映一个项目整体状况，也是用数据说话，这个站点大多数情况下是给用户看的，客户除了关心交付物，也关心项目质量，而在用户使用软件之前，最能体现质量的就是这些写在明处的报告信息。Maven出现之前可能是根据项目作出的不同阶段来提交给客户不同的成果物，比如软件的功能做完了，应该提交单元测试覆盖率报告，一般使用Eclipse插件完成，之后生成一个测试报告，也是HTML形势的。到了客户使用后出现的一些问题答疑和使用问题总结阶段，可能会出现一份word文档或者高级一点的Trace来记述客户使用反馈信息。其实这些都可以使用风格统一的Maven生成站点来体现，到最后最终的站点实际上是一份完整的项目文档，之后项目终验阶段，这份完整的项目信息站点还是很有参考价值的。

5.  Maven对于客户来说

其实前面那么多铺垫，都是为了维系客户关系，下次做项目的时候，客户招标就会多倾向你们一些。Maven功不可没，让客户觉得该公司的团队比较“专业”。开发中暴露的问题越早，改得越早，到后来客户那边反馈的问题就越少，中间的交流、沟通成本也就越低。文档越详细，客户使用中就越顺手，满意度也就越高。开发人员节省了项目周期（当然，工作量还是那么多，只不过使用Maven造成的结果是换了一种比较“高雅”的剥削方式罢了），客户付出的成本和时间也就越低，从商务的角度讲，在固定的一段时间内，固有的资金得到了更多的流动，收益也就相应提高。这对于客户来说是比较重视时间的。当然，客户可能不懂技术，但是节省的成本是实实在在的，懂技术客户可能知道Maven，如果项目引入Maven，客户会觉得团队与国际接轨，比较专业，比较靠谱，接触，勾通，包括之后的招标都是比较有利的。

总的来说Maven带来的益处是比较明显的，而且Maven也日趋成熟，使用Maven项目的团队也越来越多。