日常技术问题记录于 ISSUE，做此文以表达初衷。
《毛泽东选集》在中国革命战争的战略问题中提到：
读书是学习，使用也是学习，而且是更重要的学习。从战争中学习战争 --- 这是我们的主要方法。
一个程序员的进阶也是如此，既需要通过读书对知识有一个系统性、体系性的认知，也要不断的在碰到问题、解决问题的过程中成长。
本文想记录下这些年自己总结的经验方法，希望自己在今后的道路上能够坚持这样的方法，有朝一日成为一个优秀的程序员，做出一款让自己满意，让用户满意，为这个世界贡献价值的产品。
简而言之，方法论包含两部分：
- 善于发问，善于考证，勤于总结记录
- 系统化的梳理自己的知识体系
程序员的工作每天都在解决问题。这些 Bug 可能来自于自己的粗心，比如拼写错误，又比如思路没理清导致的逻辑错误。当然，最有价值的是因为自己认知不够所制造的错误，比如时区不一致导致的时间问题，比如对缓存层缺乏认知，导致高并发下数据库压力大，应用不可用。有的时候这些问题小到 “为什么加了这个配置就好了，去掉就有问题？”，有的时候大到 “我们的架构设计可能初始时就是错的”。所有这些问题，都是我们 “日复一日” 工作中所得到的宝贵财富。我们一定要研究透彻并且记录下来，这样子才会在看似平凡的日子里日益精进。
工作时间多数要赶任务进度，常常没有太多的时间来对一个问题窥探究竟。可以把这个问题先记录下来，我平时使用的工具是 滴答清单，可以为各种技术类目专门建一个标签，比如 docker、go、k8s 等等，然后遇到哪类问题就在对应标签下添加一下，把疑问写清楚，以备之后得空去解决的时候自己还能回想的起。
解决问题的时间还是要抽出来的，既然我们都知道宝藏在哪里了，为什么不去挖呢？这个时代的知识获得成本真的已经很低了，无论什么问题，多 google 几次肯定能找到答案。这里还是要强调一下信息源，信息源的质量决定了我们的认知质量。我们尽可能的追溯到最源头去洞悉真相，比如 ps 命令的用法，我们就去查 man ps。etcd 的原理，我们就去追 《In Search of an Understandable Consensus Algorithm》 这篇 paper。当然，这取决于我们想要认知的深度，需要根据自己能力量力而行。既要解决问题，也不能陷入解决问题的泥淖。
遗忘是一个固然规律，我们需要找到一种方法 “把金子封存起来”。我平时的做法是把解决方案记录在 GitHub ISSUE 中，类似于 滴答清单 的标签功能，我们同样可以为记录的 ISSUE 打上标签，这样日后遇到同样的问题时会方便查找。
问题的记录也是有讲究的，一点要记录好：
- 问题是什么？
- 如何解决？
- 原理是什么？
常常会发现，我们在解决 A 问题的时候，发现自己对 B 问题的认知是不够的，只有补足了 B 知识，才能解释 A 问题。这是一个很好的提升自己的过程。
日常发现问题、记录问题都是从 “点” 出发，常常我发现，自己之所以犯错，是因为对某个知识面都是完全空白的。对此，既要为了快速解决问题去快速了解一个知识盲点，也要利用空余时间补足缺失的知识面，这样子，之后遇到同样的问题才不会处于被动。
我选择购买经典的教科书籍（因为我关注信息源的质量），然后一点点的啃下去。现在回想起来，学习未知的知识肯定是需要耐得住寂寞一点点钻研的。所谓又有乐趣又速成的教程，最后学到的都是皮毛。
举个例子，算法常常是程序员被大厂拒之门外的难关。极客时间上有个很高票的课程 数据结构与算法之美，我也买了课。但我同样买了《算法导论》这本书。极客时间的课程确实能让人快速知道一二三，但是要深究原理，深究公式推导，还是要读经典教材。晓得底层原理，方得灵活运用，举一反三。
同一个知识点，你从《算法导论》上学一遍与从极客时间上学一遍收获肯定不是不一样的，具体有多大不一样，可自行去试一试。
任何不能坚持下去的事情最后都是一场空，方法论重要，开始迈出第一步去做也很重要，持久的坚持更重要。