面试大招之系统设计
在我们团队经常进行的面试中，往往会用关于算法、数据库与架构设计之类的问题来考察候选人的能力。不过我一般不会直接问，而是将这些问题安排在系统设计里面，或者也可以叫做情景题。
在一些常见的场景中，如果遇到了某些请求特别耗时间，为了不影响其它用户的请求以及节约服务器资源，我们通常会考虑使用异步任务队列去解决，这样可以快速地处理请求、只返回给用户任务创建结果，等待任务完成之后，我们再告知用户任务的完成情况。
对于 Golang，我们可以通过 Worker pool 异步处理任务，在大多数情况下，如果不在意数据丢失以及服务器性能足够，我们就没有必要考虑别的方案，毕竟这样实现非常简单。
接下来我们先来说说如何用 Worker pool 解决异步任务的问题。
最近看完了《OKR 工作法》以及《这就是 OKR》，再加上团队实践 OKR 有小段时间了，趁着热度还在，赶紧总结下。
顺便简单评价下这两本书，《OKR 工作法》整体不错，用茶叶商的故事娓娓道来，内容也很有指导性，而《这就是 OKR》整本书最有价值的地方就是它的附录资源，书的内容粗读即可。
在 Web 应用中，有一块内容非常重要，却很容易被我们忽略：参数验证，忘了之后常常会给我们造成大量的处理错误问题，甚至直接造成应用崩溃。之前我在 你的团队需要更好的 API 文档流程 提到过，Joi 的验证非常好用，可以帮助我们验证客户端用户的上传数据以及返回数据，而在 Golang 中，我们该如何做呢？
《黑匣子思维》这本书是很早之前就看过一部分的，不过忘了什么原因没看下去。这个月把这本书重新拿出来看的时候，好后悔，当初为什么不把它看完。这些天看完后，觉得我之前在 谈谈服务稳定性 提到的一些内容与观点，相比之下都过于粗浅了。
相信你在看到黑匣子这几个字的时候，会联想起飞机，我们知道，在航空业中，每架飞机都会装两个几乎无法被破坏的黑匣子：一个记录着发往机上电子系统的操作指令，另一个记录着驾驶舱内的对话与声音，一旦事故发生，黑匣子记录的数据就会被取出分析，事故原因也就一目了然。
这跟我们今天说的内容，有什么关系？现在，不妨让我们从一次作者在开篇提到的手术事故说起（以下内容涉及剧透）。
历经一个月左右，断断续续把这三部曲看完了，这部小说是之前挺火的电视剧《大江大河》的原著小说，作者阿耐，那时候看了介绍之后，本想看电视剧，但是想到看电视剧太费时间，不如看小说了，而且还能感受到原著的原汁原味，而且小说有三部，电视剧貌似只拍了第一部。
注意：以下内容会有剧透，谨慎观看。