说在前面

陆老师今天的课程从 GC 的发展历程讲起，渐次讲解了垃圾回收的流派以及基础的垃圾回收方法，从而引出 Golang 的 GC，向我们讲述了 Golang 垃圾回收的特点与触发时机，最终为我们简述了一些编程过程中可能使用到的工具和指标，帮助我们更快的找到和分析问题。

GC 基本理论

GC 的发展从 1959 年的 Lisp 语言就开始了，他所做的事情其实就是把需要程序员手动申请和释放内存这件事情自动化了，解放了程序员的生产力，能够用更多的精力放在业务代码上而不是去关心内存，经历了几十年的发展，GC 也变得越来越完善，功能也变得越来越强大了。

说在前面

饶老师从一个故事讲起，引出了调度器的概念和 Golang 的调度器模型，并深入的讲解了 Golang 的循环调度的实现和抢占式调度的实现，不禁令人感叹，Golang 的循环调度为我们的岁月静好负重前行。

循环调度的建立

所谓对 goroutine 的调度，实际上就是指 Golang 程序代码按照内置的一些算法，在运行时动态的选择合适的 goroutine 放到 CPU 上去执行的过程， 其本质是通过保存和恢复 CPU 寄存器的值达到切换 goroutine 的目的。

说在前面

云浩老师这门课程中，从引入 Golang 本身数据结构对多核性能使用不足的场景讲起，然后由并发安全问题讲起，阐述了解决并发问题的通用方案，并基于此，提出了有序链表的并行化方案，由猜想到验证一步一步引导我们实现一个在多核场景下 scalable 的数据结构，由浅入深，令人印象深刻。

并发安全问题

并发安全问题，表现为对一个变量发生更改的同时有另一个线程对同一个变量进行了读写，导致产生了不可预知的行为，也叫 data race

说在前面

冯敏老师从一个不加锁并发修改导致出现问题的例子讲起，用最佳实践匹配我们工作中的实际场景，提出一些避免踩坑的建议，从而引出锁的进化和原理。

最佳实践

减少持有时间

缩小临界区，注意 defer 的使用

通过缩小临界区的方式，可以避免在加锁和解锁之间，由于有较为耗时的代码，导致锁持有时间过长，从而造成性能问题，例子如下：

1
2
3
4
5
6
7
8
9
10

var Users = map[string]string {
    "user": "password",
}
var mu sync.Mutex
func CheckUser(name, password string) bool {
    mu.Lock()
    defer mu.Unlock()
    realPwd, exist: = Users[name]
    return exist & realPwd == password
}

乍看之下这段代码是没有什么问题的，但是如果代码像下面这样

1
2
3
4
5
6
7
8

Func SomeFunc() {
    // do sth
    mu.Lock()
    defer mu.Unlock()
    ...
    ...// long code
    ...
}

如果 defer 之后的代码特别耗时，那这个 mu 锁的时间就会非常长了，会拖慢整个程序的速度。

所谓基本功，即为我们日常工作中的专业技能，比如程序员的编码能力、系统设计能力，产品经理的文档能力、产品设计能力，销售的推销能力等，为什么说要苦练呢？因为练习基本功是一个长期持续，可能伴随着重复和枯燥的过程，热血上头坚持几天不是什么难事，难就难在长期坚持，不断缓慢的提升自己，正所谓“合抱之木，生于毫末；九层之台，起于累土；千里之行，始于足下”，就像我之前提到过的，坚持做重要不紧急的事情，可以让最终的效果达到 120% 甚至更高。苦练，不仅仅是一个形容，更是一个要求，我们都知道人最喜欢的事情就是得到快速的即时反馈，但是我们在练习基本功的时候往往无法得到即时反馈，所以才会很难坚持，才会很苦，为了跨过这个苦，我们需要设立长期目标和短期目标，长期目标是让我们有一个被指引的方向不至于走岔路，而短期目标是让我们尽可能快的获得反馈，提升成功的可能性。

延迟满足感则是苦练基本功必须具备的素质，同时也是苦练基本功可以锻炼出的一种能力，两者相辅相成，相互促进。举一个学生时期的例子，我们做题的时候，如果一道题很简单，轻轻松松就做出来了，我们是不会有什么满足感和成就感的，但是如果是一道难题，我们费尽九牛二虎之力终于做出来了，那种满足感和成就感相信大家都曾经感受过，这就是延迟满足感。同样的，在我们工作过程中，如果总是做一些自己能力之内的事情，轻易的就完成了，那我们不但没有什么满足感，还会没有任何进步。如果我们能够去做一些要花比较大的力气才能做成的事情，甚至一些自己无法独立完成，必须和他人合作才能完成的事情，这样的成长和满足感足以让我们久久回味。就像我们的 OKR 一样，其实就是为了让我们可以再往上够一够，让我们的满足感更强烈一些，让我们的成长更快一些。

说在前面

本文提供了一些 Golang 工程项目的最佳实践，分别从可读性、健壮性和效率三个方面进行描述。

Readable

可读性对于机器来说其实没有什么区别，但是对于作为开发者的每一个人来说，可读性就显得极其重要了。对于个人开发者来说，一个人不可能记住他写的每一行代码，很多时候我们自己写的代码，经过两三个月之后，我们基本上就会忘记当初写的逻辑，高可读的代码可以让我们更加轻易地进行阅读回忆；而对于协同开发来说，代码的可读性直接决定了多人合作开发的效率，高可读的代码可以让我们协作开发的效率得到巨大的提升，那么常用的代码中有哪些方式可以提升代码的可读性呢？

说在前面

我是加入字节之后才开始学习使用 Golang 的，在学习和应用这门语言的过程中，踩过很多坑，但是踩坑的同时也学习到了很多有用的知识和技巧。通过不断沉淀这些知识和技巧，我们能够更叫高效和保证质量的完成业务代码，避免造成不必要的损失。

建议大家都先去看一下 50 Shades of Go，里面涉及了 Golang 开发初期最容易踩得 50 个坑。

今天周年庆的仪式上，一鸣提到了他觉得方法论可以说是没有什么作用，抽象相当于在思维上加杠杆，是一种思考上的偷懒，并列举了一个“赋能、闭环”的例子来论证这个事。我部分赞同他的观点，但我还是觉得方法论是有其意义和使用场景的，在我看来，方法论其实是一种对日常工作工程中的经验模型的一种总结，可以帮助我们快速找到一个正确的方式来应对某些事件，比如做预案的时候，需要考虑到哪些方面的内容才能做到不缺不漏，需要联系哪些方向的同学进行共同处理，这些一点一点沉淀下来的经验我认为是一种有用的方法论，是有其实际意义的，如果没有这种方法论进行参考，下次做预案的时候又要重新去想类似的内容，还可能会有缺漏。当然如果只按照方法论沉淀下来的既定内容做事，就会出现一鸣说的“思考上的偷懒”这个问题，所以我们不仅仅要按照方法论做事情，还应该去思考这个方法论是不是适用于当前的环境，是否有更加优化的方式来进行实施，能否把当前的方法论再进行优化，这样方法论不仅能够避免犯一些人为的错误，同样也能够锻炼我们的思维，做到思考上不偷懒。

此外，我觉得方法论对于不同的人来说其实意义也是不一样的，对于已经有很多成熟经验的人来说，方法论可能会在一定程度上限制他的思想；但是对于小白或者首次经历做事的人来说，方法论可以指导他快速上手，有章法的做事，避免在并没有形成良好的工作习惯的时候犯下超过限制的错误。在框架内做事是能够防止犯大错的，总的来说方法论就像是一个框，在这个框里做事不容易犯错，但是无法做跳出这个框的事，当我们在这个框中已经形成了良好的习惯之后，我们却要敢于打破这个框，打破他的限制，让我们的思考和思想能够不断的发散，甚至于把这个框变得更大，限制更小，更加灵活。

Whwhorere 是美团提出的一个适用于产品规划和思考的方法论，其构成为 Why, What, Object, Resource, Roadmap, Evaluation，其实和我们经常提到的 5W1H 比较类似，但是更加适合用于产品规划方面。

• Why：我们为什么要做这个产品，为什么是现在做，是业务发展到了什么阶段导致瓶颈还是有其他的原因
• What：我们的产品是什么，要解决哪些痛点问题，提供了哪些能力，
• Object：我们产品的目标是什么，用哪些方案来解决提到的问题，为什么选择当前的方案，有没有其他的替代方案
• Resource：为了实现这些目标，需要使用多少资源和人力
• Roadmap：详细的产品实现路径和 milestone 规划
• Evaluation：如何评估产品做出来的效果，每个功能如何证明达到了既定的目标

使用这个方法论，可以让我们对于产品的思考更加的清晰明确，建立起一个更加直观的框架结构，也便于我们将自己的产品规划讲述给他人。

今天看到了一篇文章，讲的是一个团队指定了 A 作为 B 的上级，但是 A 却没有批复 B 的申请，给 B 打绩效的权利，B 的绩效好坏也不影响 A，久而久之 B 不再听从 A 的安排，A 也不去管 B，导致 AB 虽然是一个团队，却没有团队的合作。这个就是团队管理中常见的权责利不统一而导致的问题。

• 权，指的是团队主管拥有的权利，一般指财务权和人事权。
• 责，指的是团队主管需要承担的责任，比如团队的整体绩效。
• 利，指的是实现了绩效之后，整个团队可以和获得的收益及其分配方案。

三者之间的关系是缺一不可，相互制约又共同生效的，缺少了权就像指挥家缺少了手，无法顺畅的指挥交响乐，缺少了责容易成为“渣男”，只分派任务却不用担责，导致人心不平衡，缺少了利就是“想让马儿跑，却不给马儿吃草”，三者任缺其一都会导致管理出现问题，要做到权责利平衡，需要先做到薪资等利益和岗位责任对等，其次对应的岗位责任需要赋予对应的权利，岗位责任最大，工作难度越高，赋予的权力也需要越大，成功获取的利益大，失败承受的后果也更严重，三者相互制约，可以理清工作的边界，让我们认清工作的本质，知道什么是我需要做的，做成功能获得什么收益，这样我们工作的积极性也就提升起来了。