由于各种原因，程序员都可能接手一个全新的系统，或者一个模块，或者是一段代码功能。由于增量或者存量的业务问题，不得已要在已有的代码上做增删改查。
大部分存量的代码可能只需要简单的阅读就可以根据需求加以修改，但是如果面对的是一个沉淀了几年功能的系统，或者是非常复杂的模块，那如何能做到快速上手呢？
一、了解业务
第一个建议，就是先了解业务，不要马上就一头扎到代码里不能自拔，这也是很多入门程序员员犯的最大错误，很多程序员的视角是”代码及文档“，因此认为通过代码就可以直接复现代码功能的所有现象。虽然不能说是错的，但是在实际中会碰到很多问题，甚至自负的改动代码引起线上故障。
由于前任程序员的水平和历史背景问题，功能实现方式、历史背景、代码注释等都存在一定的不确定性。
因此通过代码直接复现业务功能是非常有难度的。要先梳理代码要实现的业务功能是什么，有很多途径可以代码所支持的业功能到底是什么。需要评估出业务的几个特点：
- 系统有没有文档、教程、分享文章等
- 代码的主要业务功能是什么
- 业务功能使用的角色是哪些，数量是多少，种类是多少
- 业务功能的运营、产品、技术负责人是谁
更好的方式，是找到运营、产品或者原来的技术负责人，简单了解业务的上下文背景，这里可以快速熟悉当时代码实现的原因和背景。毕竟代码写的时候的上下文环境和当前的环境可能是完全不同的，因此要回顾到当时的历史背景，才能更好的理解代码。
对于有条件自己走一遍产品功能的，则再好不过了，走查方式一般有以下几个方式：
- 通过客户的角度去体验一遍功能，特别是一些TOC的产品
- 通过测试账号去体验一遍功能，在系统上线的时候，一般需要自测，因此可以找到当时的账号进行验证。比如一些TOB的场景，无法通过客户的角度去体验的，就可以通过内部测试账号去体验
对于实在链路过长，无法全链路体验的，可以通过局部构造集成测试用例的方式去验证。
二、阅读代码
了解到核心、大致的业务背景后，就可以开始阅读代码，阅读代码也要分层次，首次阅读的一定是代码的骨架，即阅读和了解代码的核心流程，此时要摒弃一些代码细节的研究，可以忽略一些内部晦涩难懂的细节实现，仅仅关注主要的模块、类和方法。此时阅读要关注的重点一般是
- 入口类
- 核心接口
- 核心对象
- 核心持久化能力
完成骨架代码的阅读，就大致可以了解业务的工作流、类图、ER图，此时就可以做到对代码有个大致的框架，即知道入口在哪里、哪几个模块实现了什么功能、数据存储到哪里等。这里可以沉淀出时序图、流程图、ER图等关键的技术表现对象。
业务流程图
E-R图
当然，阅读代码，要善用IDE工具，诸如JAVA的IDEA，有很多快捷方式，比如可以查看方法的调用依赖快捷键、查看方法接口快捷键等等。俗话说的好，工欲善其事必先利其器，找到好的工具、好的工具使用方法，分析阅读代码就快人一步。
三、分析调用
如果说代码是了解系统的设计态，那么分析调用链路就是分析运行态。即我们分析完一个系统看起来是什么样的，下一步就分析系统动起来是什么样的，毕竟不运行的代码，是没有任何意义的代码。
因此分析系统调用关系，可以帮助快速了解系统的实际运行走向，分析出系统的主干链路、耗时、上下文入参、返回值等等。
这里推荐一个非常好用的开源工具：https://arthas.aliyun.com/en-us/，可以快速的分析线上调用情况。
理论上，一步步调试DEBUG代码，是可以最清晰直观的分析出代码的调用，实际上线上系统大部分无法在日常调试环境里复现调用流程，大部分的系统甚至都无法在本地启动起来。因此正常情况是结合线上&预发利用日志、在线调试等工具。
这里比较推荐用arthas来分析线上的调用情况，可以直接采集线上调用来分析代码的运行情况。
arthas可以捕获指定方法的调用链路，也可以分析指定方法的入参出参（具体参考文档）。通过上面的trace就可以快速了解到一次实际的请求经过了哪些链路，然后结合代码可以了解每个方法实际完成了什么功能。
四、深入阅读
通过上面的方法，已经有了全局的系统背景、骨架、调用链路，现在可以开始深入阅读了。根据代码的复杂度，有的部分简单有的部分会比较复杂，因此可以针对复杂的部分逐行的阅读分析和调试代码，精准的对代码块就行分析，上下文入参是什么，实现方式是什么，返回值是什么，是否持久化，是否幂等，代码能否进一步抽象，此处代码设计的是好还是不好原因是什么，能否找原先的代码编写同学讨论一下，代码是否不符合当前的需要，性能能否优化等。
这里就可以根据需求，比如是增加业务功能还是性能优化还是重构，就有不同的视角出发点对代码进行评估分析。
