前言

来自2024年11月一些文集弃文的集合。我改了一下发上来。

至于为什么变弃文了，是因为居然真的有人看，感觉表现的太中二会让人感觉当成异类。

uber阅读

interface

1.接口类型本身就是指针。如果需要修改其存储的值，需要用指针传递，这样就可以修改原值，否则只能修改拷贝值。进一步说，读可以不用指针，写的话要用指针。

2.防御性编程。由于go的规则是struct去实现interface的所有func才称作implement，因此存在可能我们漏实现了某个函数却没发现，那么原本构建的逻辑将会被打乱。而添加了一个

var 接口=空结构体

的判断，如果结构体未implement接口，则编译的时候会报错，因为他们是接不上的。这样就利用人工标注有效地弥补了机制上编译器无法弥补的东西。

type Handler struct {
  // ...
}

var _ http.Handler = (*Handler)(nil)

func (h *Handler) ServeHTTP(
  w http.ResponseWriter,
  r *http.Request,
) {
  // ...
}

3.接口被implement的时候，receiver可以是值receiver也可以是pointer receiver。

4.互斥锁sync.Mutex。由于Mutex的零值是有效地，这代表着var比new声明更好，new浪费内存。因为var是直接在栈上分配变量，而new要在堆上分配对象。如果我们要在结构体里面使用Mutex，建议是建立一个变量。

如

type SMap struct {
  mu sync.Mutex

  data map[string]string
}

而不是

type SMap struct {
  sync.Mutex

  data map[string]string
}

后者的Lock()方法，变成了SMap的方法，而前者的Lock方法是SMap.mu的方法。

5.切片与数组。因为slice和map的底层实现应该是一个指针操作者一篇底层地址。因此，他的本质也是指针。如果我们把它当成值操作容易出问题。如果是复制一个切片，记得重新开辟一片内存。

6.使用defer：这个设计纯为了防止遗忘。功能强大，不用还容易让代码变复杂。

7.channel。channel的size应该是1或0，有无缓冲的区别。这样比较干净，而且1经过设计后可以达到和所有非零数字的效果。

8.iota。Enum中常量自增神器。注意，要从1开始计数。0属于一个默认值，如果是一个正常状态，建议使用0。

9.error。

  • 最好用static定义，这样我们可以case讨论，同时省略一些同质化的内存。
  • error返回动态值，我们用fmt的sprintf。
  • 报错保持上下文简介，避免“failed to “这种语义冗余。
  • 把Err作为前缀，可以用于区分这个err是否导出。如果上一行log了就不要再return err。

10.panic。不要滥用恐慌，因为不容易排查错误。

1.书接上回，别用panic。程序内部烂了才会用，因为这样的报错一坨，太难查了。

2.原子操作使用go.uber.org/atomic（内置广告hh），比原生包用着舒服。

3.一些不好改变的东西，不要直接引用，要用结构体去new。

4.公共结构体别嵌入类型，如

// ConcreteList is a list of entities.
type ConcreteList struct {
  *AbstractList
}

5.避免init，因为init容易在代码发生变动的时候发生顺序错乱，调整比较麻烦。另外，实在要用的话，init要避免全局操作或者io操作。协程别出现。

6.strconv比sprintf更快

image-20241111193433855

7.多去声明而不是缩成一坨，往往能性能更棒。

image-20241111193605513

8.切片指定容量来提高性能

9.代码一行不超过99字符（不要太长即可）。一个项目风格要保持一致。

10.减少嵌套，如果if里面套if，不如直接拿出来两个if。

11.原始字符串可以避免转义

image-20241111195104563

12.别new。一次性声明完。

image-20241111195256356

到此就over了。原来其实大名鼎鼎的uber规范也就是一些细节上的统一罢了，我已经将小部分有启发的搬上了第零周和第二周学习笔记，希望对自己和大家都有所帮助。

k3s的pod调度

主要是利用tag。先给某个机子打上tag，然后让其他set去绑定就可以。

产品阅读

引导式设计——用户第一关

对于产品的引导式设计。我们知道很多互联网产品，都会有开局《新手教程》类似的东西，但是这种很烦，其实用户不喜欢一些乱七八糟的指导一下子涌上来，而是喜欢自己探索。apple公司喜欢采用非引导式的隐藏设计，比如左滑右滑。这会让用户在不知不觉学会这汇总用法，或者通过人与人的沟通习得一个《小妙招》。这简洁而精妙。

然后可以看到最近hz的奖学金系统。给大家做了一堆培训，却老是出现制度方面有钻漏洞行为的事情，被各种举报。首先这个是技术人员没有考虑到产品的易上手性，这也是产品设计环节没考虑清楚用户-系统之间交互而诞生的问题。辅导员不一定都是计算机毕业的，所以可能有的人压根没有那么调理清晰的工程思维来处理一些树；就算有这样的思维他也需要花很多成本去学习期中的规则，那有时候甚至不如人力excel表。这样用户会感到操作复杂，学习或使用投入成本大，不乐意花时间，把权力交给学生，所以强制使用就会出现非常多的问题。甚至差点被叫停。

后记

作为一个对奖项最忌恨的人，居然在搬上先进班集体荧幕的时候变成了只靠奖项出彩的人。回去读了之前写的《黑神话》一文，深有感慨。一是感慨就过了一个月居然都忘了之前写了什么，感觉读了新文章的感觉，震撼我居然能写出这样的句子；二是感慨我狂喷奖项，疯狂做自己热爱的事，如今已经初步完成了当初的执念，然而却在荧幕上成为了我很抵制的人。也可能有些名誉是随热爱而来的吧。进一步诠释热爱的强势。