为什么要阅读别人的代码
阅读别人代码的目的性:
- 我要评估是否引入第三方模块
- 我要给某个模块局部修改一个Bug(可能是因为使用的第三方模块遇到一个问题, 或者可能是你的上级临时指定了一个模块的Bug给你)
- 我要以某个开源模块为榜样去学习
- 我要接受并长期维护某个模块
有产出的学习过程, 才是最好的学习方式.
那么阅读源代码的产出应该是什么? 答案是, 构建这个程序的思路, 也就是架构设计.
理解架构的核心脉络
怎么做到?
首先, 有文档, 一定要先看文档. 要记住 文档和代码很容易发生脱节. 但是就算已经发生过变化, 阅读过时的架构设计思想对我们理解源代码也有极大的帮助作用.
具体来说, 看源代码的步骤应该是怎么样的呢?
首先, 把公开的软件实体(模块、类、函数、常量、全局变量等)的规格整理出来. 找到有哪些软件实体以及它们的规格, 各自的业务范围是什么, 之间有什么关系? 需要进一步分析.
下一步, 看example、unit test. 这属于我们研究对象的客户, 能够辅助我们理解各个软件实体的语义.
接下来, 我们需要进一步证实或证伪我们的结论.
当然, 如果你能够找到之前做过这块业务的人, 不要犹豫, 尽可能找到他们并且争取一个小时左右的交流机会, 并提前准备好自己遇到的迷惑的问题列表. 这会大幅缩短你理解整个系统的过程.
最后, 确保我们正确理解了系统, 就需要将结论写下来, 形成文档. 这样下一次其他同学接手这个系统的时候, 就不至于需要重新再来一遍这个过程.
理解业务的实现机制
怎么搞清楚业务流程
程序 = 数据结构 + 算法
要搞清楚业务流程, 接下来要做的事情就是, 把这些业务流程相关的数据结构先理清楚. 理清楚数据结构, 事情就解决了大半.
剩下来就是理解各个UserStory的业务流程, 并给这些业务流程画出它的UML时序图. 这个过程随时可以补充. 所以挑选对我们当前工作最为相关的来做就好了.
最后, 还是同样地, 我们要及时把我们整理的结论写下来, 变成架构文档的一部分. 这样越来越多人去补充完整架构设计文档, 才有可能把我们的项目从混沌状态解脱出来.
结语
对于任何一个项目团队来说, 阅读代码的能力都极其重要.
阅读代码是不可或缺的能力.
为什么这么说? 因为: 代码即文档, 代码是理解一致性更强的文档.
此文章为3月Day8学习笔记, 内容来源于极客时间《许式伟的架构课》, 强烈推荐该课.
