有一些有用的工具可能没有在你的工具箱里：interfacer，zb，realize 和 binstale。 他们没有什么共同之处，但他们中每一个都可以解决特定的问题。

　　interfacer: 我应该在这里使用一个接口吗?

　　interfacer 有一个非常明确的用途：查看函数的参数，并指出可以用接口类型替换的那些参数。

　　为什么需要它?

　　也许你听说过以下建议：函数期望接收一个接口然后返回特定的类型。 我不记得在哪里看到这个规则，准确的措辞可能也不同，但要点是，如果一个函数的参数是一个接口，那么这个函数会更通用，并且可以接收诸如模拟类型的参数用于单元测试。

　　所以每当你觉得错过了一个让你的函数接收接口而不是一个结构的机会，运行 interfacer ，它会告诉你答案。

　　一个例子

　　想象有一天，你开始写一个BBQ传感器库来控制感恩节火鸡的温度。 这个库中包含由 Alerter函数组成的 Alerter 接口和一个实现 Alerter 的 Sensor 结构。

type Alerter interface {
Alert()
}
type Sensor struct{}
func (Sensor) Alert() {
fmt.Println("Turkey is done!")
}

　　几个小时几千行后(是的，你感觉这一天富有成效)你定义一个函数 sensorAlert 期望接收一个Sensor 结构并调用其 Alert 方法。

func sensorAlert(s Sensor) {
s.Alert()
}

　　你模糊地记得 Alert 属于某些接口，但不记得哪一个。 你太懒了而不想搜索它(毕竟已经下午11点了)，所以你运行

　　$ interfacer bbq.go

　　得到了这条建议:

　　bbq.go:15:18: s can be Alerter

　　你快速调整了 sensorAlert 函数然后上床，因为现在你知道明天写测试时可以轻松地传递 MockSensor 结构到 sensorAlert。

　　Interfacer on GitHub

　　zb: 快速连接到go的工具链

　　在你完成一些最新项目的工作之后，运行 gometalinter。 它需要一些时间来完成，这时你发现一些lint 工具已经深入到vendor目录，现在的输出包含很多无用的消息。

　　然后你运行 go build，结果观察到测试失败了。 啊，忘了运行 go generate。

　　当你解决这个问题时，你意识到时间已经过去了，所以你希望你的工具更快，更智能。

　　zb 可以帮你解决这个问题.

　　与以前的工具相反，zb是一个小型瑞士军刀。 它提供了一堆命令来加速你的开发/构建/测试周期。 其中的一些亮点如下：

　　•在可能的情况下运行并行的go install命令加速构建.

　　•通过缓存结果加速测试和lint工具.

　　•自动调用 go generate，以防万一你忘了.

　　•了解 vendor目录，并保留了一些不在vendor中的操作(例如，linting)。

　　•我不可能在这里列出所有可用的命令; 否则最终相当于重写了 README 文件。 如果你有好奇心，可以到 zb’s README 看看。

　　•注意：作者描述这个工具因人而异，我同意这种说法。 另一方面，你也没有必要使用所有可用的命令。 只要选择你觉得有用的，不妨碍工作方式的即可。

　　•zb on GitHub

　　•realize: 通过 Ctrl-S触发你的工具链

　　•标准的go工具 - go build, go test,等是快速和简单的，但随着你的项目越来越大，越来越复杂，你开始希望某种程度上的自动化，即每次保存一个源文件时触发所有的编译和测试工具。

　　•realize 是你的朋友。

　　•激活 go build, test, run, generate, fmt等只是在配置文件中反转一些布尔型的开关(而不是指定完整的命令行)。

　　•此外，你可以添加自定义命令进行预处理和后处理，设置路径忽略，保存输出，日志或构建中的错误流等等。

　　•除了多彩的输出外壳(你可以通过颜色快速地区分构建的成功与否)， realize 还有一个在浏览器窗口中监视所有构建进程的Web UI。

　　•realize on GitHub

　　binstale: 我的二进制文件是最新的吗?

　　你知道 $GOPATH/bin 目录中的二进制文件是否仍然是最新的吗?使用 go get 命令愉快地安装一个又一个二进制文件，然后它们开始蒙尘。 在某一时刻你记得你曾经安装了一个帮你做某事的很好的工具，最终你在$GOPATH/bin里找到了它，但它并不好用并提示了一些不可理解的错误信息。

　　你确定它的运行没有问题，那么，也许二进制文件过时了? 你决定尝试更新源代码。

　　你在$GOPATH/bin 中进行递归搜索来查找与二进制文件同名的仓库。 最终你发现了这个仓库在这里执行 go get。 这样做修复了你的二进制文件，你觉得很轻松...

　　...直到你意识到在你的 $GOPATH/bin 目录中可能有几十个旧的二进制文件!

　　Meet binstale.

　　这个小工具可以立即告诉你一个给定的 go-gettable二进制文件是否需要更新。

$ binstale realize
realize
STALE: github.com/tockins/realize (build ID mismatch)

　　如果你再多花一两分钟，它可以对所有的二进制文件执行同样的操作。

$ binstale
CanvasStreamTest
STALE: github.com/cryptix/CanvasStreamTest (build ID mismatch)
Go-Package-Store
STALE: github.com/shurcooL/Go-Package-Store (build ID mismatch)
aligncheck
STALE: 
github.com/alecthomas/gometalinter/vendor/src/github.com/opennota/check/cmd/aligncheck 
(build ID mismatch)
STALE: github.com/opennota/check/cmd/aligncheck (build ID mismatch)
asmfmt
STALE: github.com/klauspost/asmfmt/cmd/asmfmt (build ID mismatch)
balancedtree
STALE: github.com/appliedgo/balancedtree (build ID mismatch)
benchcmp
STALE: code.google.com/p/go.tools/cmd/benchcmp (build ID mismatch)
STALE: golang.org/x/tools/cmd/benchcmp (build ID mismatch)
benchstat
STALE: rsc.io/benchstat (build ID mismatch)
binstale
STALE: github.com/shurcooL/binstale (build ID mismatch)
bug
STALE: github.com/driusan/bug (build ID mismatch)
...

　　你可能已经注意到一些二进制文件有多个匹配的仓库(上面示例中的 aligncheck和 benchcmp)。 因此，binstale目前不会自动更新任何二进制文件。但是只要你把仓库路径复制粘贴到get -u，更新就完成了。

　　binstale on GitHub.

　　结论

　　这些只是稳定增长的基于命令行的工具中的一些例子，它们使开发人员的开发变得更容易。