最近的一些关于分享和思考的一些想法
稍微整理下最近看到的一些学习方法
日常学习看书，往往要看几遍才能对概念保持长时间的记忆。这样的方式缺点是耗费时间且缺乏明确的重点。对于比较缺乏时间或者专注力的情况下，通读不那么费神，结果也相对低效。
读到的某篇文章的思想，只有输入，没有输出这样的效率有影响。这两天一直再回顾过去学习过程中的一些场景，在思考没有输出是否形成了过去学习过程中关键性的
输出如何定义：
- 看完能总结出大纲，关键的知识点要能回顾
- 能总结出来，并且写下来。
- 对于比较实践化的内容，最好能转化为小的project，只有实际上项目验证，才能对特别的用法或者边界理解的清楚，本质上是一个较高强度的知识强化过程。
分享的一些经历
写到这里，回顾下工作的这么些年经历的关于”分享“的事情。
以前在腾讯内网还能保持内网博客（KM)的输出频率，多次分享之后，也逐渐模糊的悟出了，写文章本质上是一个自我考验和重新思考的过程。这个过程不仅要对所分析内容比较理解，还要能有条理的表述出来。所谓比较理解是基于对写文章前的自我判定，实际上写的过程中发现对这个“比较理解”程度还是有不少问题，再强化学习补充，这样输出的结果是更进一步的。实际上KM还有一个好处，就是能扩大自己的影响力，有一次心血来潮分析了下协程的工作原理，进入了当日的KM头条，组内的同事看到了还主动贴在群里表示赞扬。输出分享，一方面自己系统的学习到了一个东西，一方面大家会觉得你是有技术的同事。
离开腾讯一年了，换了一个完全不同的环境。这里的分享，被定义成了要给其他人讲明白的内容，成为了工作的一部分。这样的有监督性的任务式分享，逐渐降低了我分享的意愿。本身大家不是特别关注技术，更倾向于业务导向，更想知道某个业务是怎么做的，坑点在哪。
一年多几乎没有这种自由的分享了，一方面公司不太拥有分享的文化，一方面也是自己比较忙，难得有空系统的思考整个过程。这次重启博客，做一些自己想做的事情，不应该受限于工作。
知识的强化训练
以最近看的书. Design System Interview 为例，第一次看到 Back of the envelope 一张半页的表，看到一眼茫然，这么多的数字怎么记得住。实际上经历了一周已经完全将这个表格记录下来了。具体的流程是这样的：
- 每天早晨起来第一件事，拿着一张纸仔细回忆这个表格，想到多少写多少
- 写不出来的再看看答案
- 反复的持续一周，这样对内容非常熟悉
有了对这样一个内容的熟悉，开始思考这一步实际上对应我们以往开发过程中的那些内容，以及这样一个 cheatsheet 承担了什么样的作用
系统设计需要的基础知识主要是对可能涉及的服务有一个大概的评估，下面罗列一些：
- 我要用数据库，有哪些数据库，优缺点是什么，单机性能多少，当前场景下最少的服务数量是多少
- 我要用消息队列，和1一样的一系列问题
- 泛化成，xxx服务，有哪些实现，优缺点，单机性能，需要部署多少
实际上通道面试也就在干这个事情，评委会问你，为什么要这么设计，xxx的性能是怎样的，你是怎么考虑的。实际上就是一些通道专有的 Back of the envelope.
这里讨论的关注点还是知识的强化训练，因此不打算在系统设计面试或者通道上过于展开，基于看书的经验，以及其他场合所需要的闭卷能力，需要我们平时有这样一个表，属于自己领域内的 Back of the envelope。这样才能做到心中有数。而且一开始你计划做这个表格，就会遇到一开始的一眼茫然，完全记不住的困扰。这一节就是介绍这样的场景用到的流程。
常用的服务性能或者类型罗列
- mysql单机QPS 4k+QPS
- redis单机QPS 8W+QPS
- 消息队列选型和性能参数
- 常见的一些性能 java vs c++ (1.2-2.0性能差异)
总结
日常学习一方面基于兴趣，一方面也要面向Interview。兴趣使你能更积极的投入，面向Interview 能学到或者get到再用但是没有系统总结的一些技巧和知识。要及早的准备自己的Back of the envelope，这样针对日常设计或者面试都能做出初步的合理判断。查资料是一种更靠谱的方式，但是实际上有人开始问你时，你无法立刻去访问资料库，这些内容如果经过加工的强化记忆会更合理。
关于分享，还是要系统性周期性的坚持，把短期还能留在脑海中的东西写下来，形成长期内容。