接手项目要做的事项

总结：在接手别人的项目时，至少应该自己整理并绘画四个图

1、产品脑图：帮助你理解产品的功能；

2、UML时序图：帮助你源代码的核心技术实现；

3、整体业务泳道图：帮助你从整体上熟悉业务的流程；

4、系统架构图：帮助你掌握目前服务器的部署情况和网络链路。

熟悉产品、熟悉业务、熟悉技术

接手一个旧项目，第一要义：尽快熟悉你的产品。这个产品具体主要功能是什么？是给谁使用的？客户群体是谁？目前大概注册和使用的用户有多少？上游供应商是谁？项目组的其他成员还有哪些？等等这些项目和产品背景信息都要搞清楚。

第二要义：尽快熟悉业务。业务很关键，你要对接手的产品所在的行业有一定的理解和学习。也就是我们通常所说的特定领域的业务。这个业务到底是做电商、还是做广告、还是做游戏、还是做ToB的系统集成，不同领域的术语和知识也不同。

第三要义：快速了解当前项目所用到的技术栈、编程语言、开发框架、数据库、环境要求等。技术是基础。

开始开发一些小需求和小功能

当你要开始开发新的需求时，先不要着急去改代码。

因为，你会发现，写代码很简单，但要写出100%符合原来业务逻辑和规则的代码就很难。

也就是说，编程语言的代码语法不难，难就难在完整理解和全盘掌握原来代码的业务逻辑。

为此，你可以使用ProcessOn、Xmind、Viso等在线工具或本地软件，先自我梳理一遍目前产品和技术上的思维脑图、核心业务逻辑的时序图、整体业务流程的泳道图、目前系统的架构图。至少可以梳理这四个图。

例如，产品功能的思维脑图梳理，帮助你了解产品的功能和形态。通过点击、浏览、体验和使用产品的每一个页面，你可以边操作边梳理。

然后，打开本地IDE代码编辑器，找到对应页面和接口背后的源代码，定位到最底层、最核心、最重要、最复杂的代码模块，边浏览源代码、边整理核心的时序图。这一块工作，可以让你抓住项目的底层本质和核心，熟悉原来的代码风格、编程范式、设计模式、高并发的处理方式、各模块的依赖关系等。

第三个图，是整体业务的泳道图。它可以让你知道整体的系统上下游的数据流向、底层的依赖系统和网络链路。当你的系统出现问题了，你知道可以找谁。

最后一部分是面向技术架构的系统架构图。这部分，你可以通过nginx日记、或者阿里开通的服务、以及内部记录的资料找出你的系统都调用了哪些第三方接口。例如短信接口用的是哪家？有没用到OSS对象存储？CDN用了什么？数据库是用云服务还是自建的？你要清楚地知道目前有多少台服务器，是如何部署和相互调用的，网络链路是怎样的。从用户发起请求打开页面开始，系统在背后都做了哪些事情？

接手实战经验：