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