Go语言目前(截至1.0.2版本)尚不支持直接链接.a文件(这里的.a文件指的不是传统静态共享库，而是对golang的非main包build后的产物)。这样一来Go的第三方库包或组织内部的公共代码库包只能以源码的形式分发了。

Go提供了get命令用于获取他人分发的代码包。我们通过get命令既可以获取一些知名代码托管站点上的代码，也可以获取组织内部版本控制服务器上的公共代码。

Go get支持的托管站点包括github、google code、BitBucket以及Launchpad，针对这类情况，我们可以得到“特殊”语法的照顾：

go get github.com/bmizerany/assert
go get bitbucket.org/bmizerany/assert
go get code.google.com/p/assert
go get launchpad.net/assert

由于Go已经“内置”了github、google code等的版本控制工具类型，因此我们无需再做任何额外指定，只需用代码的url（去掉http://）即可。

执行get后，代码会被下载到GOPATH环境变量配置中的第一个路径下的src目录下面。例如：我们的GOPATH=/home/tonybai /goworkspace1:/home/tonybai/goworkspace2，执行go get github.com/bmizerany/assert后，我们将在/home/tonybai/goworkspace1下看到github.com 目录，而assert包在本地的完整路径就是/home/tonybai/goworkspace1/github.com/bmizerany /assert。这样我们在代码中直接import "github.com/bmizerany/assert"即可使用assert这个第三方包了。

在组织内部我们也会有自己的私有公共代码库，一份代码库可能被多个项目所使用。在每个项目中都保存一份公共库代码显然是不利于后续版本升级维护的，这样就需要各个项目统一从同一个地方获取或更新公共库代码。这种情况我们同样可以用go get命令来做。

假设内部使用subversion作为版本控制工具，公共库架设在10.10.12.13/svn0/share/golib。这时我们不能简单地的通 过"go get 10.10.12.13/svn0/share/golib"来获取到代码，我们需要告诉get我们采用哪种版本控制工具，而这种信息的传递是通过在库名称后面加上后缀的方式进行的。比如：

go get "10.10.12.13/svn0/share/golib.svn"

这样在/home/tonybai/goworkspace1下就会出现10.10.12.13/svn0/share/golib.svn目录结构。我 们在代码中可以直接import对应的包，比如import "10.10.12.13/svn0/share/golib.svn/assert"。

通过对get命令特性的了解，我们也可以确定分发的代码包到底应该如何组织。从上面的例子我们可以看出我们分发的代码包结构不需很复杂，直接在库的 repository下建立包目录即可，比如上面例子中库repository为golib，assert就是直接建立在下面的目录，同时也是包名。

go get可自动识别http_proxy环境变量，这样Go也可以通过代理获取外部代码包。

使用外部代码包的项目可以通过go get -u url来更新代码包版本为最新版本。

近期产品线出现这样一个“怪现象”：许多已经完成编码并具备提交给测试组的版本没有测试人员对应。测试部那边给出的策略是：按版本优先级从高到低依次测 试。这样一来一些重要版本需要到3个月甚至更长时间之后才能开始测试。可以肯定这种现象是生产环节的一个问题，但用什么理论去解释和分析这个问题呢？我想 到了“库存” – 软件库存。

《Joel说软件》的那个Joel曾写过一篇名为《软件库存》的文章，也正是看了那篇文章后，我才第一次了解到软件库存这个概念。库存似乎是传统制造业中 的一个概念，但软件开发其实也是广义产品生产的一种，虽然有其特殊性，因此有些产品制造方面的理论是可以应用于软件生产过程中的，软件库存就是其中之一。

传统制造业的库存较为容易理解，零件、原材料、半成品以及未卖出去的最终产品这些都可以理解为库存。而软件生产中的库存都包含哪些内容和环节呢？一旦形成库存，利弊又有哪些呢？

* 未纳入开发的需求/特性

这里所说的需求/特性是经过决策后将来要开发的且能带来价值的，而不是为了大而全而滥芋充数的那种。这类需求/特性可理解为已经采购并存放在库中尚未投入 生产的原料库存。这类库存如果变得很大，则很可能说明产品市场场景甚好，但也可能是现有的生产能力出现了不足；如果这块库存过小或没有，则会导致后期开工 不足，或者说产品的持续成长前景黯淡，市场对其的需求也不乐观了，组织对此情况应做出迅速反应。

* 已经开发完毕但未经测试的半成品

开发人员开始投入，根据需求/特性疯狂编码、单元测试，生产出未经专业测试的半成品。这些半成品因其中潜在的许多缺陷而不能作为最终商品投放市场，因此无 法收回成本并赚取利润。一旦这个环节形成库存，则说明后续质量验证环节的生产能力与软件开发环节的生产能力出现了不匹配，这将导致版本中的问题不能尽快地 暴露，使得问题流向其他版本或其他系统中，直到测试开始后才能发现，后续要花费更多的工作量做关联的修正。这也是我所在产品线所遇到的棘手问题，唯一的方 法就是提高质量验证环节的生产能力，至于如何提高，因地制宜，这里不表。而较小的库存或这个环节无库存，也会导致后续质量验证环节的开工不足，或衔接出现 节奏性的问题。

* 未上市或未卖出的成品

当产品顺利通过质量检测部门的测试后，便可正式发布，变成最终产品- 成品，交付到最终用户那里。但如果这个环节出现库存，问题将变得严重得多。要么是前期市场估计过于乐观，要么是行销人员不给力，要么则是生产过剩，没有做 好库存管理等等。如果这个环节库存过小，则最终客户依旧无法及时得到产品，不利于保持客户粘性，客户很可能退而求其次，选择其他厂商的产品了。

以上简要分析既提到了不能忽视库存的存在，也说到了无库存的危害。传统制造行业一直在追求着一种“零库存”的概念，所谓“零库存”，是指物料（包括原材 料、半成品和产成品等） 在采购、生产、销售、配送等一个或几个经营环节中，不以仓库存储的形式存在，而均是处于周转的状态。它并不是指以仓库储存形式的某种或某 些物品的储存数量真正为零，而是通过实施特定的库存控制策略，实现库存量的最小化。在软件生产领域也可借鉴这一概念，在各个环节努力维持合理且适当的库 存，这对整个生产过程是大有裨益的。

可以看出“零库存”的一个精要就是及时收回产品的投资，获得利润，保持生产过程的持续有效进行。这让我想到了当今软件过程的演化：从最初的瀑布过程到目前 流行的迭代和敏捷等过程，以及流行的持续交付等概念，它们似乎都是在追求“零库存”，追求快速回流价值。或者说库存理论潜在地催生了敏捷、持续交付等概念 的迅速发展，并让人们看到其中的裨益所在。