读源代码的目的就是了解架构。
我认为首先要找出来软件实体，然后理一下软件实体之间的关系。看源代码，我们首先要做到的是理解系统的概要设计。概要设计的关注点是各个软件实体的业务范畴，以及它们之间的关系。有了这些，我们就能够理解这个系统的架构设计的核心脉络。
要理一下各个软件实体的业务范畴，以及它们之间的关系。有了这些，我们就能够理解这个系统的架构设计的核心脉络。
有文档就先看文档，哪怕文档偏陈旧，我们再看源代码，就可以相互进行印证。
具体来说，看源码的步骤应该是怎样的呢？首先，把公开的软件实体（模块、类、函数、常量、全局变量等）的规格整理出来。这一步往往有一些现成的工具。例如，对 Go 语言来说，运行 go doc 就可以帮忙整理出一个自动生成的版本。一些开源工具例如 doxygen 也能够做到类似的事情，而且它支持几乎所有的主流语言。当然这一步只能让我们找到有哪些软件实体，以及它们的规格是什么样的。但是这些软件实体各自的业务范畴是什么，它们之间有什么关系？需要进一步分析。一般来说，下一步我会先看 example、unit test 等。这些属于我们研究对象的客户，也就是使用方。它们能够辅助我们理解各个软件实体的语义。通过软件实体的规格、说明文档、example、unit test 等信息，我们根据这些已知信息，甚至包括软件实体的名字本身背后隐含的语义理解，我们可以初步推测出各个软件实体的业务范畴，以及它们之间的关系。接下来，我们需要进一步证实或证伪我们的结论。如果证伪了，我们需要重新梳理各个软件实体之间的关系。怎么去证实或证伪？我们选重点的类或函数，通过看它们的源代码来理解其业务流程，以此印证我们的猜测。
要搞清楚业务流程，接下来要做的事情是，把这些业务流程相关的数据结构先理清楚。数据结构是容易梳理的，类的成员变量、数据库的表结构，通常都有快速提取的方式。
理清楚数据结构，事情就解决了大半。剩下来就是理各个 UserStory 的业务流程，并给这些业务流程画出它的 UML 时序图。这个过程随时可以补充。所以我们挑选对我们当前工作最为相关的来做就好了。
