uber_go_guide解析(一)

前言

实力有限,guide啃着好费劲
原地址https://github.com/xxjwxc/uber_go_guide_cn
加我自己的体会和补充
基于Golang 1.14

正文

Interface 合理性验证

在代码编译时验证接口的合理性, 通过 var 一个空变量的方式,如果你的接口没有实现好, 在创建变量时会报错

感觉不实用

接收器与方法

如果我们建立map时value不为指针的话,我们是无法使用接收指针的方法的,因为map的value可变

Mutex锁

mutex锁的默认值就是有效的, 因此在生成锁的时候不用new就行

如果是结构体加锁,这个结构体在内部使用,那么无需给这个锁设立字段

反之则需要

在边界处拷贝 Slices 和 Maps

注意Maps和Slices的值是可变的,所以更改内存地址的值会导致真正的值发送变化


此风险同样存在于返回值中

同样使用copy可以解决

使用defer释放资源

defer本身消耗非常小的资源,尤其是1.14版本又大大优化了defer
所以使用defer来进行文件关闭等操作,大大提高可读性,同时避免忘记关闭的情况和中间出现问题导致没有执行关闭的情况

channel的大小是1或者是无缓冲

在使用channel时,应该考虑好channel的大小,梳理好逻辑流程,将channel大小设置为1或者无缓冲是最好的和最常见的

从1开始枚举

在go中,实现枚举通过设置const和iota,由于枚举从1开始,但是iota初始值为0,所以记得iota+1

当然在某些情况下,从0开始时有益的, 他表达的意思可能是, 如果你枚举时从0开始,但是因为创建新int类型的变量时默认值是0
此时如果你拿着变量去枚举就乱了.但是当你把0枚举成一个默认的值就没有问题,但是一般枚举是这样用的

就算你使用 Operation(变量) 强转然后调用方法也是会返回Error因为都不匹配

使用time包处理时间

时间的处理其实是比较复杂的逻辑,比如每月几天,时间换算等
所以使用官方的time包可以节省更多的开发时间
需求1: 计算这个时间是否是活跃的(当前时间大于任务开始时间且小于结束时间)

需求2:时间参数

需求3:计算24小时后的时间

在与外部的交流中也使用标准时间格式化格式,例如
命令行格式化通过 flag 包的 time.ParseDuration
json通过 json 包的 UnmarshalJSON
sql 将 DATETIME 或 TIMESTAMP 列转换为 time.Time
yaml 也支持 time.Time 格式等等
无法强行适配对接,也可将其转化为时间戳进行发送,当然这一切都必须双方约定好,并且要在JSON的字段名里体现出这是时间戳