5 深入代码层
当你对数据库表做了以上到了解后，你基本上对这个系统能提供什么服务了解到差不多了。这个不论你的代码长什么样子，数据库摆在那里，其实能提供的服务就已经差不多出来了，对于有经验的人来讲，代码的业务逻辑也大致能猜到个八九分。
我认为一个业务相关的项目代码只分三个部分：
- 通过交互对自身数据库进行增删改查操作
2. 通过定时任务或服务器脚本对自身数据库进行增删改查操作
3. 调用或通知其他服务做一些事情
如果只是单一项目，无非就是通过各种途径去玩自己的数据库而已，前两点足够了。而如果是微服务部署，那么加一个第三点足矣。我们将代码逻辑分成这三个部分看，快速了解一个项目就不成问题，甚至在你没有看过某一项目而突然有一个bug要你解决时，你也可以按照这种方式去快速定问问题。
通过交互对自身数据库进行增删改查操作：这个无非是最简单的一部分，即使复杂也是代码较长，表较多而已。所谓的交互，或许是Controller暴露给前端用户的接口，或许是开一个rpc端口暴露给其他微服务的接口，总之是第三方去触发的。这里我也给自己做了个小工具，扫描出所有的暴露服务的接口，展示出方法名，路径名，参数列表和返回值等。和数据库一样，如果接口很少那么一个个看，如果特别多，还是先找出比较核心的几个方法研究。这里我用的是postman，把要研究的接口访问保存起来，并且添加访问成功和失败的Example。这里我推荐自己开发的时候也把postman用起来，越详细越好，postman不只是可以简简单单访问你的接口，还能做批量测试，还可以生成api文档用于和前端交互。这样你不但测试了自己的接口，还省的写文档了。而且postman还有个好处就是可以给自己的接口mock一个服务，这样即使你的接口挂了，或者你的接口根本就没写好，你可以让前端人员先访问你的mock，完全不影响前端边测试边开发，这才是真正的前后端分离嘛。整理出所有接口后，肯定大部分是很简单的，一看就懂，一层一层点进去直到数据库层的sql语句，该接口最本质的东西就出来了。如果是复杂的，那就一步一步debug，花时间总是可以分析的。如果再复杂的，你可以画流程图（这里我比较推荐用processon）。甚至几个接口围绕一个功能的，你可以画状态流转图。比如我之前看我们公司处理订单业务这块，逻辑确实比较复杂，我就画了类似如下的具有程序员视角的状态流转图（这里只是示例图）：
状态流转图：横轴代表order_status字段的状态，纵轴代表当order_status是以上状态时，触发该接口操作会使该字段发生什么变化）
订单表 order_status 状态流转
0-待支付 1-已支付 2-已取消 3-退款中 4-已退款 5-退款失败
支付成功异步通知来了 -->1 报错 报错 报错 报错 报错
用户发起退款 报错 -->3 报错 报错 报错 报错
退款成功异步通知来了 报错 报错 报错 -->4 报错 报错
退款失败异步通知来了 报错 报错 报错 -->4 报错 报错
接口对表的影响图：这里你可以把所有涉及到的表以及表中的关键字段列举出来，然后看分别调用接口后对各个表字段的影响，变化的就用红色标出
有了这两种维度的视角，我相信再复杂的业务都能很理清楚，也能发现某些bug最本质的问题。我正是通过这样的方式，把一个本来不属于我的项目短时间内了解清楚，快速准确地修复了好多顽固的bug。虽然项目很烂，业务逻辑十分混乱，但正是这样一段时间锻炼了我深入代码理清逻辑的能力，也有了自己独特的一套方法。
通过定时任务或服务器脚本对自身数据库进行增删改查操作：这个和第一种类型一样，只不过换了个 入口。如果有些问题你发现并不是交互而产生的，那你就要寻找其他入口。比如定时任务，或者启动的时候就开启的一些线程。寻找这些入口的确不是特别容易，比较头疼，但也只是入口比较隐蔽而已。找到他，记下来，具体分析过程还是按照上述方法去分析，就可以了。
调用或通知其他服务做一些事情：上述两种代码如果你都摸得差不多了，整个项目对自身的玩法基本你已经摸透了，那还剩一小部分就是它和其他服务之间的交互。代码中一定有通过mq给其他服务发消息，或者直接调用其他服务的接口，或者调用类似云推送的接口让它去帮忙像mq发消息。总之不管形式如何，都只是为了rpc其他服务而已。这部分代码可能更加隐蔽，但数量少，逻辑也简单，你需要做的仍然只是找到它们。这部分也是为了解项目之间的关系打下伏笔。
这三种类型的代码研究清楚后，对于一个业务型的项目来说，已经基本足够了。对于一些基础服务和中间件类型的服务，还是得慢慢积累技术深度才行，了解过程仍然也是可以有规律的，只不过需要更底层的方式去分类，比如将代码分成资源的加载，模式的匹配，等等。由于本篇文章是快速了解一个业务型的项目，所以就不展开叙述了。
6 重新理清项目间的关系
好了，这时候每个项目你已经大致了解，最起码调用的效果，数据库所能提供的服务，甚至某些关键部分的本质逻辑，你是清楚的。这个时候，要重新整理下项目之间的关系。
根据之前的接口名称，详细了解下项目间的调用关系。理不清的部分去问老员工，这时候你带着自己的了解问，他们也能给出更多的信息。
看看每个项目中用到的中间件，主要是mq服务，看看谁是生产者，谁是消费者，以此来了解关系
这时你应该已经开了好几轮的周会了，接下来的周会你应该能听懂部分内容。根据每个人的描述和最新的几组需求，逐渐摸清楚现在项目面临的问题，以及哪个项目是核心，哪个项目是辅助，哪个项目是以稳定安全为主的
到此为止，整条业务线你就有了大致的了解，接下来就要结合你具体负责的内容，领导安排你做的方向，去看具体的业务代码了。深入其中，事无巨细地了解。但此时，你通过前面的努力，你已经可以站在一定的高度看每一个项目了，虽然你细节上还是不了解，但这是完全不同的。在研究具体业务代码的同时，不断地跳出来看整条业务线的框架，修正之前由于不了解具体业务而理解错误的架构。长此以往，你一定会在某个项目中脱颖而出，让大家认识到你的全局视野，这也是走出老是写增删改查代码怪圈的一个途径。慢慢会有人意识到，你对项目的理解总能站在全局的视野，很多需要跨项目去做的业务，也会自然而然想到你，慢慢地，你会接触到更为核心的东西，成为架构师，或者去转向产品，转向管理。
参考
