如何熟悉一个陌生系统

在日常开发过程中,我们经常需要去承接一个陌生的系统,而且承接的系统都很复杂,那我们应该如何快速去熟悉一个系统呢,有哪些思路和切入点呢,下面从业务和技术以及实操3个层面来分享一些心得体会。

业务层面

在熟悉一个系统之前一定是先熟悉业务再熟悉技术,切不可本末倒置,下面是熟悉业务的一些要点。

1.业务背景

系统都是为业务服务,所以要了解系统为公司的哪块业务服务,在所有的业务域里处于一个什么样的地位,实现什么业务目的,有什么业务价值,如果没有这个系统,公司业务是否有影响,影响范围是多少,是否能正常运转。

2.业务图谱

大部分系统都可以通过两个纬度来梳理出一个业务图谱出来,一个是流程纬度,比如创建、审核、下传、回传等X个流程。另一个纬度是场景纬度,比如每个流程需要支持Y个业务场景,将X与Y组合起来,就可以形成一个矩阵式的业务图谱。通过业务图谱的拆解和整理,对于业务的各种逻辑就有了全貌的了解。

3.使用情况

可以从分两方面来了解使用情况,一个正常使用情况,也是从宏观层面,比如该系统有哪些部门用户在使用,有哪些用户角色,主要是B端用户还是C端用户,如果是B端用户,是一线用户还是管理层的用户,用户的结构分布是什么样的。每天系统的用户使用量有多少,流量(PV/UV)分别有多少,流量可以衡量一个系统的重要程度,尤其是峰值流量。还有系统的用户

另外一个是异常使用情况,是从微观层面参与处理系统异常问题,也就是系统运维问题,运维问题就像一双无形的手,在背后推着你,能倒逼你更深入了解系统的业务和逻辑。



技术层面

在前面所述,已经对系统的业务有了一个全面的认知,在业务认知的基础上,接下来就需要熟悉系统的技术实现了。

1.技术架构

首先需要了解的就是系统的技术架构,基于什么底层架构实现,使用了哪些中间件技术,代码层面需要了解代码实现的结构,基于什么样的原则分包分层。

2.数据存储

系统使用了哪些数据库,哪些是系统本身产生的数据,哪些是依赖的外部数据,有多少数据表,核心业务存储在哪些表,每个表存储什么样的业务数据,重要表的数据每天每周每月增量是多少

如果存在多种数据库的存储,需要了解清楚数据库之间的数据同步机制,是否存在延时情况,这个延时是否会产生运维问题,是否会影响业务使用。

3.外部交互

很多系统都不是独立存在的,都需要和外部很多系统进行交互,那系统依赖的外部接口,提供了哪些接口供外部使用呢,这些内外部接口分别承担了什么样的功能和作用,其重要性如何,重要接口的SLA分别是多少。

4.系统部署

系统应用部署了哪些机房集群,每个集群有多少个节点容器,如何实现负载均衡,系统应用的相关性能指数如何配置的,高峰值的负载是多少。

5.系统问题

如果要熟悉一个系统,从系统反馈的问题出发来了解会让人印象更深刻,比如通过监控能收集到很多的报警问题,就可以从监控问题入手,了解问题所在的模块以及相关代码和业务,一步一步顺藤摸瓜,分析产生问题的原因,最终推进解决问题,这些分析问题解决问题的过程,其实就是逐步的熟悉系统的过程,当然前期分析问题可能还需要同事的支持和帮助,否则有的问题,如果对系统不熟,还是很难解决的。



实操层面

以上这些思路都是从宏观层面或者从某个视角去熟悉系统,但是由于我们的系统都是由每一行代码编织而成,所以最直观的方式还是需要从代码层面去进一步熟悉,才能更深刻的理解系统所实现的功能以及系统如何实现的。代码层面有很多方式,比如可以通过开发一个需求或者修改一个Bug来熟悉代码和相关功能。



最后使用一个思维导图来总结以上的要点:



相关推荐
用户526354238699 小时前
# Chrome 扩展实现网页文字与语音同步高亮
产品
人月神话Lee10 小时前
我做了个不要账号、不要定位权限的旅行 App,聊聊那些「不做」的决定
ios·ai编程·产品
怕浪猫12 小时前
第8章 从0到1全流程产品设计
产品经理·产品·资讯
星期一研究室12 小时前
告别文档「图片灾难排版」!3大黄金法则,让你的文档从杂乱无章到杂志风🧩
微服务·产品·设计
怕浪猫1 天前
第7章 产品需求文档(PRD)撰写
产品经理·产品·资讯
星期一研究室1 天前
飞书多维表格的「色彩规则」,让数据流转像红绿灯一样清晰!
微服务·产品·设计
ElevenWang2 天前
我为什么开始用语音输入代替键盘打字
aigc·产品
怕浪猫2 天前
第6章 交互原型设计 — Axure 实战
产品经理·产品·资讯
星期一研究室2 天前
代码块:长文中的‘荧光浮标’!让「关键内容」无损高亮呈现
微服务·产品·设计
南巷羽3 天前
用 TRAE Work 把 20 条 GitHub Issue 变成可复核的需求优先级清单
github·产品