大家好，我是 Z 哥。

所谓“跳槽爽，一直跳槽一直爽”。但是，世上哪有那么好的事哦，跳槽虽然可以带来更快的涨薪机会，但是你也是要面对和克服一些新挑战的，其中最大的挑战莫过于要熟悉一个陌生的项目。毕竟，进入到一个新的团队，又恰好遇到做的是一个新项目，这个概率就太小了。

对我们程序员来说，这里的陌生项目就是一套陌生的源码。

有时候如果运气好，有一位带教老师或者热心的同事来帮助你熟悉项目，那自然会轻松很多，速度也更快。

但是如果你运气没那么好，或者去到了一个人员紧张的快速发展期企业，那就只能靠你自己了。这个时候如果你掌握了一些快速熟悉项目的技巧，会对你有很大帮助。

否则，因为没能在一定时间内对项目有足够的了解，导致工作完成得不好，进一步导致没过试用期，那就麻烦大了。

很多人熟悉项目，先从其中用到的中间件开始。这个思路其实不太好，虽然中间件是通用的，在哪个项目里都能用，所以比较容易下手。但是具体怎么用，承担了什么职责，在一些细节上，不同项目会有所不同。

所以从中间件入手去熟悉项目，就犹如管中窥豹，了解的并不全面，甚至可能会判断错误。

在 Z 哥的职业生涯中，大多数时候都没有什么人来指导，自己摸石头过河熟悉过大大小小十几个项目，也积累了一些经验，在这里和大家交流一下。也欢迎你在评论区分享你的好方法。

我的思路总共分为 5 步。我相信，沿着这个思路来熟悉项目，不敢说对项目了如指掌吧，至少可以在短时间内了解项目的 6、7 分。

/01  从哪里来/

“从哪里来，到哪里去”是一个著名的哲学问题，其实这个逻辑也适用于我们熟悉一个陌生项目。

大部分情况下，技术都是为业务服务的，所以任何项目都是为了解决某一个问题而诞生的，因此，「从哪里来」自然藏在业务里。

建议可以从以下两个问题入手，搞清楚了这两个问题，相信你也知道了这个项目的由来。

1. 谁在用这个系统？

2. 用这个系统做什么？

其实你会发现，这两个问题构建的是一个画面，一个人或者一群人在如何使用这个系统进行工作的画面。这其实就是所谓的工作场景，它们也解答了「从哪里来」这个问题。

举个例子，比如说你接手了一个消息通知类的系统，那么经过了解会得到这样的一条信息。

运营人员会用这个系统发送APP通知、短信通知等，以此来触达消费者，并引导用户促成交易转化。

进一步你也会知道，这个系统的职责就是编辑通知内容、发送通知、记录触达的结果。如果更进一步的话，还能考虑到点击率、转化率等数据记录，因为这些数据可以更好的帮助操作人完成他的工作目的，“促成更多的交易”。

/02  到哪里去/

第一步搞清楚了「从哪里来」，下一步搞清楚「到哪里去」。

「到哪里去」就是搞清楚这个项目生命周期，这个项目实际是如何运转创造价值的。这其实也是必要的一个前期准备工作。毕竟不管做任何事，有准备总是更好的。没有准备，谈何事半功倍呢。

第一步主要需要做两件事：

1. 知道源码在哪里。

2. 搞清楚项目运行涉及到的环境。这里的环境不仅仅是生产环境，还有各个测试环境和 CI / CD 机制。

只要知道了这两项内容，其实你对这个项目的「生命周期」就了解的很清楚了。知道了它是如何流转的，就相当于知道了它到哪里去。

/03  梳理技术链路/

在第一步中我们做的工作其实间接也算梳理了一遍业务链路。基于这个信息其实我们也可以进行技术链路的梳理了。

对于技术链路的梳理，我的建议是，「先纵再横」。

「纵」就是沿着一条线从前往后梳理，一般从应用侧开始， 应该很多人也的确是这么干的。比如上面我们在前面例子中提到的通知系统，一般是，UI -> API -> MQ / DB -> 各个通知渠道的 Service -> DB。

「横」就是对梳理出来的多条「纵」的技术链路进行整理，找到其中的共同点以及相关性。这些共同点大多会由一个通用组件/ Service 来满足需求，而相关性则代表着多个业务链路之间的「耦合」关系。

当然，如果你参与到的是一个超大型项目，很多「纵」其实已经单独做成一个子系统了，这个时候对「横」的梳理，其实就是对子系统之间的梳理。

注意，做技术链路梳理的时候，不需要陷入到代码细节里去，只要大致知道不同 class 之间的引用关系如何即可。如果你提前深入到代码细节里去，那么一但遇到复杂度较高的项目，你很容易产生焦虑感。

/04  梳理数据表/

如果说站在整个业务的本质上看，业务无非就是一堆代码运行在一堆机器上；那么站在单个项目来看，一个项目无非就是对数据库的增删改查操作而已；或者从使用者的角度看，一个项目就是输入一些参数得到一些返回结果而已。

工欲善其事必先利其器，梳理数据表我平时最喜欢用的工具是 Red Gate 里的 SQL Doc 和 SQL Dependency Tracker。前者可以自动根据数据库的信息生成方便查看的文档，后者可以生成图表查看数据之间的关系，很好用。

如果遇到一个表数量达到 3 位数的时候，怎么能快速定位核心表呢，有 2 个小技巧。

1. 忽略 config、log、flow、statistics 为后缀或者前缀的表，这些的表的作用从名字也能看出来作用，必然不会包含什么核心业务信息。

2. 从一些前缀统一的表，但是前缀不属于上面 4 个单词的表开始。比如 order、trade 这种，一般越核心的业务，往往基于它前缀所扩展出来的表也越多。

/05  运行并调试一下/

调试是一个有效的 Debug 方式，也是一个有效理解代码的方式。我们进行调试的目的倒不是为了弄清楚某一个业务的细节，而是通过调试来观察数据的流转情况，验证自己对之前做的这些信息整理所形成的猜想是否属实。

因此，尽量挑选一个你认为业务最复杂的页面，然后对页面上的每个按钮都去点一下看看。在这个期间你还能加强对前后端之间通讯方式的理解。

前阵子写过一篇《帮助阅读源码的 8 个技巧》，里面有些思路其实是类似的。

最后再多说几句感想，我知道有很多人在熟悉项目的时候会吐槽原来的设计多么多么垃圾。我劝大家善良，因为可能未来接手你现在负责的这个项目的人也会这么吐槽你。但实际上我相信每个人在当时作出的决策设计，一定是在当时综合各方因素后的最优解，毕竟没有人那么傻，明知故错。

另外，以下这三点也是在我们熟悉项目的过程中可以相信的事情。

• 你遇到的问题很多人已经遇到过并且解决了 。 

• 你遇到的问题大概率在当前系统里面已经有了答案。 

• 你遇到的问题大概率在你用的框架和组件里面都有现成的解决方案。

好了，总结一下。

这篇呢，Z 哥和你分享了我对如何快速熟悉一个项目的经验。我的思路主要分为 5 步：

1. 从哪里来

2. 到哪里去

3. 梳理技术链路

4. 梳理数据表

5. 运行并调试一下

希望对你有所帮助。

对很多人来说，更愿意重头做一个新系统而不是去接手一个老系统。不过，老系统其实满是宝藏，里面有很多你可以借鉴和学习的东西。

推荐阅读：

• 这个时代最重要的技能之一
  

• 对DDD的常见误区
  

原创不易，如果你觉得这篇文章还不错，就「点赞」或者「在看」一下吧，鼓励我的创作 ：）

也可以分享我的公众号名片给有需要的朋友们。

如果你有关于软件架构、分布式系统、产品、运营的困惑

可以试试点击「阅读原文」