如何阅读源码3¶
为何要读别人的代码？¶
备注
阅读别人的代码，通常会带有一定的目的性。完整把一个系统的代码 “读懂” 需要极大的精力。所以明确阅读代码的目标很重要，因为它决定了你最终能够为这事付出多大的精力，或者说成本。
目标分为这样几种类型:
1. 我要评估是否引入某个第三方模块
2. 我要给某个模块局部修改一个 Bug
可能是因为使用的第三方模块遇到了一个问题
可能是你的上级临时指定了一个模块的 Bug 给你
3. 我要以某个开源模块为榜样去学习
4. 我要接手并长期维护某个模块
备注
读懂源代码真的很难，它其实是架构的反向过程。它类似于反编译，但是并不是指令级的反编译，而是需要根据指令反推更高维的思想。
阅读源码的产出¶
备注
有产出的学习过程，才是最好的学习方式。阅读源代码的产出应该是什么？答案是，构建这个程序的思路，也就是架构设计。
学习有几个层次:
1. 读懂
2. 能复述
3. 转换成自己的语言说出来
4. 说出来能让别人听得懂
5. 说出来能让很多人听得懂
理解架构的核心脉络¶
理解架构的核心脉络的步骤:
1. 首先，有文档，一定要先看文档
2. 看源代码
理解系统的概要设计。
概要设计的关注点是各个软件实体的业务范畴，以及它们之间的关系。
有了这些，我们就能够理解这个系统的架构设计的核心脉络。
看源码的步骤:
1. 把公开的软件实体（模块、类、函数、常量、全局变量等）的规格整理出来
可以借助现成的工具(如go doc)
2. 看 example、unit test 等
这些属于我们研究对象的客户，也就是使用方。它们能够辅助我们理解各个软件实体的语义。
初步推测出各个软件实体的业务范畴，以及它们之间的关系。
3. 进一步证实或证伪我们的结论
如果证伪了，我们需要重新梳理各个软件实体之间的关系。
怎么去证实或证伪？
选重点的类或函数，通过看它们的源代码来理解其业务流程，以此印证我们的猜测。
4. 确保我们正确理解了系统，就需要将结论写下来，形成文档
备注
业务系统的概要设计、接口理清楚后，通常来说，我们对这个系统就初步有谱了。如果我们是评估第三方模块要不要采纳等相对轻的目标，那么到此基本就可以告一段落了。
理解业务的实现机制¶
备注
只有在必要的情况下，我们才研究实现机制。研究实现是非常费时的，毕竟系统的 UserStory 数量上就有很多。把一个个 UserStory 的具体业务流程都研究清楚写下来，是非常耗时的。如果这个业务系统不是我们接下来重点投入的方向，就没必要在这方面去过度投入。
目标就很重要:
1. 如果我们只是顺带解决一下遇到的 Bug，我们自然把关注点放在要解决的 Bug 本身相关的业务流程上
无论是用第三方代码遇到的，还是上级随手安排的临时任务，
2. 如果我们是接手一个新的业务系统，我们也没有精力立刻把所有细节都搞清楚。
这时候我们需要梳理的是关键业务流程。
怎么搞清楚业务流程:
程序 = 数据结构 + 算法
1. 数据结构是容易梳理的，类的成员变量、数据库的表结构，通常都有快速提取的方式
MongoDB 可能会难一些，因为弱 schema 的原因，
我们需要通过阅读代码的方式去理解 schema。
更麻烦的是，不确定历史上经历过多少轮的 schema 变更，这通过最新源代码可能看不出来
一个不小心，我们就可能会处理到非预期 schema 的数据。
2. 理各个 UserStory 的业务流程，并给这些业务流程画出它的 UML 时序图
这个过程随时可以补充。所以我们挑选对我们当前工作最为相关的来做就好了。
参考¶
【极客时间】许式伟的架构课/06软件工程篇