人生无法避免之错------分析Maven的依赖
上一个Sprint总结会中，组内有人提出很多需求为什么会变化，这样搞的开发人员多累啊。为什么一开始就不采取最后决定的方式去做，还一定要折腾下呢。恰好最近看了小道消息一篇关于试错的推文，很是感触。
这点上我承认在沟通管理上没有及时发现组内成员的情绪，而且也没充分让开发人员参与到整体设计过程中，让他们缺少对整体的认识，也没很好的调动他们的积极性。
但是，就是在为什么一开始就不采取最后决定的方式去做这点上，我没法赞同的更多了。的确，需求上的改动，是因为经验，或是能力的问题，或是组织环境要求或是，更或是客户有了新的想法。开发人员就觉得你很脑残啊，为什么不早发现，早你干嘛去了。
对于这个问题，首先我觉得不少人混淆了“试错”和“错误”两个事情。而修改功能过程中，都会出现新的问题，而且在代码走查中，发现了很多代码不够健壮，比如通过连接获取信息只获取一次而没有设定超时时间循环获取导致出错，这些都会引入BUG。所以，功能修改的时候发现修改难度过大，那就得先看看自己做的事情是否不够严谨，自己设计的是否不够周全。
有些偏题，回到主题上，每个人也都无法一次就找到正确的方式，乔布斯也是在不断的试错。特别是项目组走的是敏捷开发道路，一般都是简单实现，之后扩展，就是在不断的重构，如果完全拒绝修改、更正。
之所以开发人员会产生误解，主要我觉得是问题反馈的对象的问题。基本上领导、评审人员、客户都是将问题反馈给我，而开发人员又没想去了解这些反馈，甚至在评审会议上打瞌睡觉得事不关己。总之试错是为了让产品更好，能不断进步。如果一个软件完全不用修改，那是因为他没人会去用，没有反馈的问题。
========分割线=========
之前两片基本上把Maven部署和Helloworld的过程以及过程中可能出现的问题都说到了。这篇就来说说Maven的依赖。
依赖类型
Maven会用到的依赖基本就是5种，compile，test，provided，runtime，system
1.compile：编译依赖范围，默认使用该范围。编译、测试、运行都有效
2.test：测试依赖范围。支队测试的classpath有效。例如Junit，greenMail。
3.provided：对编译和测试有效，对运行无效，常用于容器提供了的运行环境。例如servlet-api，容器以提供，所以只需要编译和测试有效即可。
4.runtime:运行时依赖范围。例如jdbc驱动，编译和测试并不需要，只需要使用JDK提供的JDBC接口即可。
5.system:系统依赖范围，依赖Maven仓库意外的依赖。
例如
<dependencies> <dependency> <groupId>javax.sql</groupId> <artifactId>jdbc-stdext</artifactId> <version>2.0</version> <scope>system</scope> <systemPath>${java.home}/lib/rt.jar</systemPath> </dependency> </dependencies><dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>2.5.6</version> <exclusions> <exclusion> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId> commons-logging </groupId> <artifactId> commons-logging </artifactId> <version>1.1.0</version> </dependency>
<properties><springframework.version>2.5.6</ springframework.version></ properties>