学习方法论

后端的常见问题

如何学习一门新的技术

为什么学习

paradigm shift。是否对你提高认知水平有所帮助。如果总是学习相似的东西，只能缓慢地提高认知水平，无法跳跃式发展。
alternative solutions。是否是已有解决方案的一个很好的替代品。我们学东西，总是要学以致用，来更好地解决现实世界中的问题。方法越多，你 trade off 的空间就越大
more efficient sometimes productivity

学习哪些

如何学

首先感性认识，花几个小时快速了解其纲领性的内容
接着了解其历史（尤其是为什么诞生，怎么诞生的了解一个技术起源和发展历程，能让你更深入地掌握和明晰技术的优劣，以及为什么会产生这种优劣）
然后熟悉其 eco system，也就是周边的各种工具
然后是 learning by practicing
然后是与人切磋比武，GitHub，pull request（and code review）几乎是这个世界上可能最好的师傅带徒弟的方法，你涉猎越广，就会有越多的师傅
接下来是对比印证。你已有的知识体系和你正在学的知识体系间是很好的参照物，通过相互对比，相互印证，对二者都会有更深刻的理解
最后是传道授业解惑 —— learning by teaching。

production ready
代码有完整的 linting / testing
项目和现有的 CI pipeline 集成
有清晰的版本管理方案
可以和现有的系统无缝对接
有完善的部署脚本
和现有的日志系统以及错误报告系统集成
和现有的监控系统集成

知识的分类
第I类知识：具体知识。
第II类知识：归纳的知识。
第III类知识：演绎的知识。

我们先把可供自学的资料列出来，分析一下：

Tutorial（入门教程）。由该项技术的官网提供。通常是英文的。这份资料是给初次接触该项技术的人看的，一般是一步一步地教你完成某些例子。当我们说某项技术对于新手不太友好的时候，一般也是因为这项技术的Tutorial部分做得不够好。
Specification，简称Spec。这是集中体现该项技术的设计思想的东西，是高度抽象的描述。这个一般也是一份完备的、系统的描述，包含该项技术涉及到的方方面面。这部分资料在不同的地方叫法不同，在相对简单的技术项目中，也可能没有；在另一些情况下，这部分资料混杂在其它文档资料之中；它还可能以论文（paper）的形式出现。
API Reference。大而全的API索引和文档，针对不同的语言接口可能提供多份。当我们使用这项技术进行编程的时候，API Reference自然是个离不开的、总是要不停去查询的一份资料。
别人写的技术博客。质量良莠不齐，到底有没有价值，我们要学会去分辨。
技术书籍。跟技术博客类似，质量有好有坏。稍后我们和技术博客放在一起来分析。
Source Code。如果我们要学习的技术是开源的，那么很幸运，我们能得到源代码。这是一份终极资料。

自述文件驱动开发-Readme drive development

如何做好文档记录，包括代码注释，项目readme编写，前后端API文档，项目通用规范等等
gollum文档管理 markdown + git = wiki

"方法论是在前人的基础上，少走弯路"