总结:在接手别人的项目时,至少应该自己整理并绘画四个图
1、产品脑图:帮助你理解产品的功能;
2、UML时序图:帮助你源代码的核心技术实现;
3、整体业务泳道图:帮助你从整体上熟悉业务的流程;
4、系统架构图:帮助你掌握目前服务器的部署情况和网络链路。
+ 部署图
+ DB库表ER图
+ 外部系统(其实也包含在系统架构图中)
+ 代码结构(单体服务or微服务,各模块功能)
+ 技术栈(框架、组件等)
+ 运营数据现状(接口请求量、kafka消息量)
+ 服务保障(日志、调用链、监控、告警)
熟悉产品、熟悉业务、熟悉技术
接手一个旧项目,第一要义:尽快熟悉你的产品。这个产品具体主要功能是什么?是给谁使用的?客户群体是谁?目前大概注册和使用的用户有多少?上游供应商是谁?项目组的其他成员还有哪些?等等这些项目和产品背景信息都要搞清楚。
第二要义:尽快熟悉业务。业务很关键,你要对接手的产品所在的行业有一定的理解和学习。也就是我们通常所说的特定领域的业务。这个业务到底是做电商、还是做广告、还是做游戏、还是做ToB的系统集成,不同领域的术语和知识也不同。
第三要义:快速了解当前项目所用到的技术栈、编程语言、开发框架、数据库、环境要求等。技术是基础。
开始开发一些小需求和小功能
当你要开始开发新的需求时,先不要着急去改代码。
因为,你会发现,写代码很简单,但要写出100%符合原来业务逻辑和规则的代码就很难。
也就是说,编程语言的代码语法不难,难就难在完整理解和全盘掌握原来代码的业务逻辑。
为此,你可以使用ProcessOn、Xmind、Viso等在线工具或本地软件,先自我梳理一遍目前产品和技术上的思维脑图、核心业务逻辑的时序图、整体业务流程的泳道图、目前系统的架构图。至少可以梳理这四个图。
例如,产品功能的思维脑图梳理,帮助你了解产品的功能和形态。通过点击、浏览、体验和使用产品的每一个页面,你可以边操作边梳理。
然后,打开本地IDE代码编辑器,找到对应页面和接口背后的源代码,定位到最底层、最核心、最重要、最复杂的代码模块,边浏览源代码、边整理核心的时序图。这一块工作,可以让你抓住项目的底层本质和核心,熟悉原来的代码风格、编程范式、设计模式、高并发的处理方式、各模块的依赖关系等。
第三个图,是整体业务的泳道图。它可以让你知道整体的系统上下游的数据流向、底层的依赖系统和网络链路。当你的系统出现问题了,你知道可以找谁。
最后一部分是面向技术架构的系统架构图。这部分,你可以通过nginx日记、或者阿里开通的服务、以及内部记录的资料找出你的系统都调用了哪些第三方接口。例如短信接口用的是哪家?有没用到OSS对象存储?CDN用了什么?数据库是用云服务还是自建的?你要清楚地知道目前有多少台服务器,是如何部署和相互调用的,网络链路是怎样的。从用户发起请求打开页面开始,系统在背后都做了哪些事情?
接手实战经验:
- 开通各种资源权限:云账号、git、流水线、机器部署、监控、告警、日志、配置文件管理、网关、负载均衡、数据库、redis、ES、产品体验账号
- 体验产品功能、梳理功能脑图、产品服务的客户、用户和数据量级、qps等
- 整理服务调用的第三方接口、第三方依赖、消息监听、消息发送、存储方式(数据库、缓存、ES、COS……)、CDN、服务部署方式
- 梳理服务的定时任务、服务启动时初始化内容、拦截器过滤器的内容
- 本地启动服务、配置文件管理方式、发布上线流程
- 准备日常查问题处理问题的工具:常用数据库查询语句SQL等
业务(项目是业务的一环) —> 产品(项目) —> 代码(技术栈)
切记勿一开始就一行一行代码的抠,需要开发或者修改代码的时候再细看,否则既容易把自己绕晕又低效,需要快速全局把控,然后快速做需求,根据情况平时再细细梳理到完全掌控。