查看原文
其他

每次跳槽,总得面对这摊事

Zachary 跨界架构师 2021-09-27

这里是Z哥的个人公众号

每周五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. 运行并调试一下


希望对你有所帮助。

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



推荐阅读:


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


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

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

可以试试点击「阅读原文

: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存