好吧，入职三个月了，终于开始正式能够了解这个项目的组织结构了。以下内容不会涉及到公司的具体业务。仅仅从库管理的角度来描述一下我开始能学到的东西。
我们工作中离不开各种库，比如说SSH框架，就有Struts2，Spring，Hibernate的Jar包，更多的，分词，图像处理等等。
当然了，如果一个项目完完全全的是一个公司完全从轮子造起，在开始的时候库管理不会太难。但是等到项目逐渐的进入到了维护和升级阶段库管理就开始变得困难了。更不要说现在项目更多的依赖于别人写好的开源库。
开源库的优点在于，当有人维护的时候功能总能够更新更快更强（理想大部分状态下，不排除有的程序猿越做越烂），但是更新更快更强就代表着接口有可能发生改变，不管项目开始的时候抽象接口做的有多好，最终在某个时间点一定会发生了变化。这带来的是建造整个项目的基础有可能发生了变化，这时候我们就要稳定压倒一切了。那么库不再升级了，保持项目开始的版本就好了。
首先第一个想到的肯定是在项目底下手工建立一个Lib，里面装满了确定的不会变化的库，问题在于，如果这个项目是一个人进行维护就还行，两个人也能接受，十个人呢？带来的沟通成本会剧增。一个公司的新人不一定能够了解到这个库在于项目的编译顺序甚至有的新程序猿就是一种新的最好的做法，很容易就导致了之后代码提交的错误，放在生产环境中就不能够接受的。
应运而生的就是附加在各种版本控制的管理软件中，比如Subversion，git，cvs等等的代码管理软件，请注意，是代码版本控制的软件。没错这样的确可以，如果只需要一个版本的库，但是来看看一下场景：我有一个库我称之为v，它有两个版本，旧的1.0，新的1.1，称之为v1.1，v1.0吧，那么v1.0提供了A，B两种方法，v1.1提供了B，C，那么当我在一个Project里面的不同Module采用了不同版本的v，这时候就会造成很大的混乱。
库版本控制软件就诞生了，当然了，以上只是陈述了为什么要库版本软件。实际用到的库版本软件每种语言都有，下次好好写Maven（Java的库版本管理），以及以后的Groovy。