我是一个着迷于产品和运营的技术人，乐于跨界的终身学习者。欢迎关注我的个人公众号「跨界架构师」
每周五11：45 按时送达～
我的第「207」篇原创敬上
大家好，我是 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.运行并调试一下
希望对你有所帮助。
对很多人来说，更愿意重头做一个新系统而不是去接手一个老系统。不过，老系统其实满是宝藏，里面有很多你可以借鉴和学习的东西。
推荐阅读：
如果你喜欢这篇文章，可以点一下右下角的「爱心」，支持我的创作～
定期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些深度思考。
网友评论