前言
作为程序员，会有许多场景需要阅读到源码，在工作中理解别人写的业务代码，在学习过程中阅读、借鉴开源项目源码。本篇文章主要涉及如何阅读业务源码，避免在熟悉新的业务过程中走弯路。
为什么阅读源码
我们阅读别人的代码，通常是带有目的性的，它决定了我们需要阅读哪个模块，需要理解到什么程度。对于支付、电商、金融等复杂的业务，理解完整的项目代码需要付出极大的时间成本，甚至说这是不可能完成的任务，因此需要我们权衡成本和收益。
概括来说，我们会在以下场景阅读别人的代码：
- 接手新的业务，需要长期维护某个模块
- 以学习为目的，学习项目的优秀设计
- 需要修复某个模块的bug
- 来自业务需求，实现一个新的功能或者更改现有业务流程
- 接入第三方组件
为什么说目的很重要？阅读源码是从实现倒推架构设计的过程，其中由于历史原因、代码年久失修导致的技术债、快速的业务迭代等种种原因，看懂源码是一个很难的过程，相信有过相关经历的人深有体会，所以需要根据目的有选择的阅读
如何阅读业务代码
梳理核心脉络，也就是概要设计
有文档，一定要先看文档
文档相当于我们理解一个项目架构设计的“外挂”，一头扎进源码阅读往往看了半天还一脸懵逼。我们需要收集项目相关的文档，但并不是说有文档都要阅读的，先了解顶层设计，知道模块之间的边界和各自的职责。 需要注意的是，并不是所有文档都是对的，可能文档是最初的设计，与当前实现已经脱节了，但这仍然有帮助于我们理解该架构的设计，最好同时在我们阅读源码的过程中更正文档。
阅读核心数据结构
程序 = 数据结构 + 算法 对于业务实现的代码来说，数据结构是程序的核心生命力，我们可以通过了解类、实体、模块的数据结构，就大概能知道实现的业务功能。数据库的设计也是核心数据结构，我往往会以数据库设计作为了解一个模块的切入点。
阅读测试用例（单元测试、集成测试）
测试用例是程序的使用方，也可以说是业务程序的服务对象，我们可以从测试用例的使用姿势中，推测业务逻辑，然后再看具体细节时不断假设-验证-推翻。
理解具体业务的实现机制
前面我们已经理解了架构的设计、核心数据结构、核心接口负责的业务逻辑，回到阅读源码的目的，如果我们只是需要了解核心业务、评估接入第三方组件，这时候已经差不多了，没必要转进具体的代码细节。
只有在必要的时候研究代码细节
研究业务实现代码细节，是十分耗费精力的，不仅仅是浪费时间的问题，有时候就算你花了许多时间，还是没能理解到位，甚至会理解错误，这一点是很难受的。其中用户故事很多，缺乏当时实现的背景，虽然看懂了是什么，但是不理解为什么，相信这一点很多人碰到。
接下来说一下如何搞清楚业务流程。
理解关键业务逻辑
如果我们需要修复一个bug或者修改部分业务逻辑，我们只需要关注该部分的代码就好了。
梳理关键业务逻辑和涉及的数据结构，人脑对关键信息的记忆是有限的，超过7步后就很容易把之前的忘记，所以说在不同维度上拆分业务步骤很重要。
可以借助IDE理清楚各个类之间继承、组合的关系，同时会显示方法和数据结构。
学习的过程是需要产出的
前面工作已经把业务梳理得过半里，剩下就是繁琐的各个场景下的用户故事了，我们只需要找到目的相关的业务代码，用心看就好了。过程中需要把用户故事梳理成UML流程图或者泳道图（推荐使用plantuml），整理成文档，避免后来的人不断重复这种逆向的过程。
积累问题，找到熟悉项目的人交流
在阅读的过程中，往往会碰到许多不理解的问题，记下来形成一个问题列表，再找到相关人集中交流，这会大大缩短你理解项目的时间。
更上一层楼
在项目可持续运维的过程中，了解业务的代码只是一个起点，如何在之后的工作中更加“优雅”，这是一个需要长久思考和实践的过程。 我想从技术视野和业务视野两个角度阐述我对项目可持续迭代的理解。
技术视野
好的代码设计，一定是建立在理解后不断重构的基础上的。
我一直认为，想要写好代码，要建立在总结反思的基础上，这里包括对自己过去写的代码，也包含别人写的代码。在阅读业务代码的过程中，不仅能借鉴别人优雅的设计，也能识别出代码的”坏味道“，试想一下如果是自己实现会怎么做。
结合自己的理论基础和经验，思考目前的设计实现时候合理，毕竟已有的实现是建立在固定的历史背景下的，随着时间的推移可能不使用了。
业务视野
跳脱当前业务边界，站在大部门、公司甚至行业的全局视角，去理解项目的设计模式。
对于刚进入一个业务领域的工程师来说，很难设计出好的架构，良好的业务架构是建立在对业务充分理解的基础上的，我认为这是业务领域技术专家的门槛。我们一开始接触项目，很难理解清楚业务架构设计的思想，常常会带着自己以往的经验去套当前的设计。足够了解大背景和所处的阶段，才能更好的看懂当前的设计，以至于提出之后演进或者优化的方向。
借鉴学习大公司、当前优秀的相关项目，学习其中优雅的实现，审视当前的设计是否合理，以及如何改进。
这是一个很难的过程，需要不断的积累和思考。
总结
因为最近接触了新的业务，需要熟悉相关的项目，根据自己这段时间的思考记下方法论。
总的来说，阅读项目代码是一个由粗到细、由关键到次要、自顶向下理解的过程，同时需要借助文档、IDE、思维导图等工具的帮助，及时找到熟悉业务得人交流。最后，提到如何从阅读项目中学习和演进优化的方法。
