首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >真实|技术人员该如何接手一个复杂的系统?吐血推荐这几招

真实|技术人员该如何接手一个复杂的系统?吐血推荐这几招

作者头像
一猿小讲
发布2020-11-03 15:01:28
1K0
发布2020-11-03 15:01:28
举报
文章被收录于专栏:一猿小讲一猿小讲

阅读本文大概需要 5 分钟。

作为程序员,无论是小菜还是老鸟,都会因为离职交接或者岗位异动等各种原因,而避免不了要如羚羊奔跑版的速度接手一个复杂业务系统。因为只有尽快熟悉系统,方能够快速支持业务需求的研发。

那么,问题就来了?面对一个一无所知的复杂的系统,我们该如何入手呢?

本文将结合菜菜同学多年来的沉(经)淀(验),再融合老中医望闻问切的招式,吐血整理成一副图和一剂锦囊妙药,送给大家。

《一剂良药》

「菊花」看文档,记疑惑。

「薄荷」串文档,理脉络。

「莲心」讲系统,要知彼。

「荷叶」捋代码,了梗概。

玄参」盘经验,理大坑。

芦根」亲操刀,细解剖。

《一幅脑图》

1

第一招:看文档,知脉略。

老中医:望。望诊,是对病人的神、色、形、态、舌象等进行有目的的观察,以测知内脏病变。

菜菜同学结合「望诊」而独创快速接手一个复杂系统之招式一:看文档,知脉略

当一个复杂的系统要交接到你手上时,理想中各种文档样样全,要啥有啥,而现实啪啪打脸。多数情况下都没有文档,如果有一些文档可看,无论质量如何,都是一件值得庆幸的事情。

如果项目组比较规范,沉淀了一些入门文档、产品介绍文档、业务架构设计文档、数据库设计文档,那就更值得庆幸啦,静下来仔细去看,通过文档多少会了解一些系统的前世今生,对系统有一个初步的认识。

不过,当接手一个系统时,一定要看看文档在哪里?是在 Wiki 上,还是在 SVN、Git 上,如若有文档的情况下,尽快找到它,并粗略的看一遍。

看了这么多文档,肯定有太多的疑惑,先拿小本本记下来,制造机会请老鸟给你答疑解惑。

2

第二招:听细节,聊全局。

老中医:闻。闻诊,主要是听患者语言气息的高低、强弱、清浊、缓急……等变化,以分辨病情的虚实寒热。

菜菜同学结合「闻诊」而独创快速接手一个复杂系统之招式二:听细节,聊全局。

拿着你事先记录好满满疑惑的小本本,组个会议,喊上老鸟好好给你指点迷津。

首先,请老鸟串一串文档。

大概理一理,然后把你之前小本本上的问题,一股脑抛出来当面请教。

然后,请老鸟讲一讲系统。

大概要了解一下系统的使用方是谁?系统依赖的系统有哪些?系统主要干系人有哪些?系统研发的需求来自于哪里?最重要的是要请老鸟演示一下如何把系统跑起来?跑起来后功能该怎么用?

最后,请老鸟捋一捋代码。

大概捋一捋代码的设计,了解一下主要分为几大块?程序入口在哪里?技术栈是啥样子?... ...

3

第三招:问疑难,解杂症。

老中医:问。问诊,通过了解既往病史与家族病史、起病原因、发病经过及治疗过程,主要痛苦所在,自觉症状,饮食喜恶等情况,结合望、切、闻三诊,综合分析,作出判断。

菜菜同学结合「问诊」而独创快速接手一个复杂系统之招式三:问疑难,解杂症。

首先,问老鸟:要接手的系统,历史事故都发生过哪些?

为了不贰过,要了解一下要接手的系统,历史的事故是代码问题,还是人祸导致的?

最后,问老鸟:要接手的系统,坑在哪里?

大概了解一下老鸟以往趟过的那些坑,前车之鉴必是后车之师。重点了解系统有哪块会有潜在的问题,当接手之后一定要细心着重对待,防患于未然。

4

第四招:亲操刀,细解剖。

老中医:切。切脉又称诊脉,是医者用手指按其腕后桡动脉搏动处,借以体察脉象变化,辨别脏腑功能盛衰,气血津精虚滞的一种方法。

菜菜同学结合「切诊」而独创快速接手一个复杂系统之招式四:亲操刀,细解剖。

通过前面三种招式相结合,我们文档也看了,系统功能也了解了,历史事故也知道了,接下来要进入程序员最擅长区域——解剖代码。

首先,加注释,加关键日志。

找到程序入口,根据自己的理解,一步一步去加注释,要敢于动手去加,确定不了的,有疑问的用注释标记好,或者记个大大的问号,把你的想法理解都用注释记录一下,相信对代码的理解,一遍比一遍更透彻。

当然,除了加注释的一种方式,还推荐加关键日志,因为加入关键日志,不过日志最好有一些特色,例如都还有「haha:」,这样能够在子模块调用比较复杂的情形下,在项目启动后,根据加入日志文件,直接关注「haha:」就能把相关子系统的调用流程串在一起,屡试不爽。

然后,跑应用,Debug。

除了加注释,加关键日志能够理解代码逻辑外,Debug 也是推荐的一种方式,从程序入口开始逐步进行调试,也会对代码有一个质的理解。

仁者见仁智者见智,依据个人习惯,还是更推荐加日志,或许是因为 Debug 有些时候遇到反射或者库调用,跟着跟着就乱掉了。

在这里,建议一定要把应用跑起来,只有跑起来,才能根据之前加入的日志,梳理梳理系统调用关系,模块调用关系,再好好体验体验功能。

最后,画画图,善分享。

加日志、加注释、Debug 的事儿多数铁子都干过,但是能把自己对代码的理解真心画下来的估计会很少,这块真心推荐大家没事的时候静下来画一画,是对代码理解质的一次提升,画出来才能理解的更透彻,更清晰,如果闲暇之余把上手系统的经过写成手册,相信对于后面接手的同事而言是一大笔“财富”。

当然了,除了画图、写手册还是不够的,重要的是能够拉几个同事进行分享一下,这样才能更快变成自己的知识,在这里忍不住要抛一张图。

另外,接手系统解剖代码这块放到最后一部分去谈,原因这块确实考验个人的技术能力,而且是一个长久的过程,需要慢慢去磨。

5

真心寄语

本次主要谈谈如何快速接手一个系统?吐血推荐的一幅图和一剂药,如果有接手系统的困惑,而且没有更好的方法时,那不妨拿去实践,屡试不爽。

前路漫长,人生实苦,每个人方法都不一样,条条大路通罗马,选择适合自己的。奔跑是追梦人的气质,用奋斗定义人生价值,在奔跑中抵达远方,铁子们加油?。

好了,分享就到这里,希望对你有帮助。一起聊技术、谈业务、喷架构,少走弯路,不踩大坑。会持续输出原创精彩分享,敬请期待!

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-10-31,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 一猿小讲 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档