大多数情况下，下划线_都用于忽略函数返回值的情况。最近查看authboss这个开源库的代码时，发现这样一种用法:
struct User {
...
}
var (
assertUser = &User{}
assertStorer = &MemStorer{}
_ authboss.User = assertUser
_ authboss.AuthableUser = assertUser
)
原文，向原作者表示感谢。这里省略了一些无关的介绍说明以及过于简单的说明，直接看代码就懂了。
在大多数语言中你可以随便放置花括号的位置，但go语言不一样，你可以理解为为go会自动注入分号（automatic semicolon injection）：
错误代码：
package main
import "fmt"
func main()
{ //error, can't have the opening brace on a separate line
fmt.Println("hello there!")
}
编译错误：
/tmp/sandbox826898458/main.go:6: syntax error: unexpected semicolon or newline before {
正确代码：
package main
import "fmt"
func main() {
fmt.Println("works!")
}
原文，省略了一些无关的内容。
如果你搜到这篇文章，那么什么是gin以及casbin应该不用过多解释了。
原文，向原作者表示感谢。不过不知道作者是不是在国内学过作文，让我想起了小学时老师教的作文要多引用名人名言哈哈。
几年前当我还是个菜鸟的时候，我过得十分潇洒。
写代码——交给别人review——改代码，绳命是多磨美好！工作内容就是仔细阅读我收到的评论、建议，学着成为一个更优秀的开发者。如今我成长为了一名高级开发人员，给别人做code review成为了我的职责之一，这时我意识到我的经验还不足以完成这种职责转变。
每次给别人做code review时我都感觉到害怕，感觉自己像是一个骗子，很多问题都困扰着我：
我该给这行代码提建议吗？
应该有更好的办法写这段代码，我应该告诉他吗？
他会怎么想？他的经验比我丰富。
改了这一行代码会不会使程序崩溃？
这时我的导师给了我建议。
好的code review聚焦于获得额外的产出，而非仅仅是找到bug。别把review当做是审讯，而当做是一种提高代码质量、发现其他方案、增加学习能力以及加强友谊的办法。
作为reviewer，你对代码的反馈是将渴望贡献的开发者组建成社区的一种主要方法。通过培养一个活跃的社区，你将提升产品、团队、和人生的质量。
这里有一些做好code review的建议。
原文，文章作者也是《Hands-On Dependency Injection in Go》的作者，向原作者表示感谢。
你是否曾经由于添加某个新功能却导致另一个功能出问题？修复好这个，另一个又出问题，就好象打地鼠一般。
你是否曾经花费大量的时间调试Bug，最后却发现问题潜伏在另一个、甚至毫不相关的模块中？
这些问题都是由于高耦合引起的。
在这篇文章中，我们来使用解偶的方式来让代码更加易于理解、维护、测试。
原文，阅读之前请先看200行GO代码实现区块链1 和 200行GO代码实现区块链2。
如果看到这了相信你已经知道什么是加密算法等背景了，所以忽略关于这部分的翻译，直接从编码开始。这篇文章在前两篇的文章基础上添加了工作量证明(POW)挖矿算法。