如何快速离职?离职交接工作清单(前端)

前言

这是一篇前端离职项目交接清单(front-end handover checklist)。

仰天大笑出门去，我辈岂是蓬蒿人？ 金三银四就要到了，大家一定跃跃欲试，甚至已经收获了很多offer。

即将入职公司：同学请问下周可以入职吗？

当前领导 or HR： 同学申请离职需要提前一个月申请，交接结束后才可以同意离职！

本文这边准备如下前端项目离职交接清单，如果我们找到了新的工作需要准备哪些东西可以完美交接并快速离职~

为什么要准备交接清单？

假设你离职已然成为事实，领导和HR很少会特别去卡时间，其实更多的是希望新的人员可以完美接受你现有的工作，所以我们要准备好交接清单，让接手人员熟悉项目，快速成为曾经的你尤为重要。

当我们找到了新的工作，无论如何我们一定在当前公司学到了很多东西，即使有负面的情绪，我们也要感谢现有的平台，提高了我们抗压能力，就算离开我们也要于赞扬中转身。

交接清单（描述版）

辅助文档方面

• 项目代码地址；

  用途： 代码地址这个肯定是必需的，巧妇难为无米之炊；

• 项目接口文档地址；

  用途： 代码请求的后端接口地址，用于后续改参数，更换接口之类的需求；

• 项目UI设计稿/原型地址/项目历史需求列表文档；

  用途： 这个必不可少，用于新需求的确认以及问题的及时排查；

• 项目现有问题/待优化问题;

  用途： 可以帮助接手人员快速明白当前项目存在问题，可能存在的坑和漏洞；

• 目前是否有需要迭代的功能；

  用途： 接手人员可以确认跟进当前未完成的需求。

• 项目功能及作用；

  用途： 知其然才能知其所以然，我们辛辛苦苦的写的东西，一定得把它的功能、优势等等等等描述的栩栩如生。

• 当前项目可能关联人员；

  用途： 让接手人员出现问题，可以及时寻找对应人员，不必再来与我们多次交接。

代码方面

• 项目代码目前技术栈、使用框架版本；

  用途： 需要确认清楚代码使用的框架及使用的版本，版本不同之间的差异也很大，防止接手人员踩坑；

• 项目结构的整理文档；

  用途： 我们可以尽量把目录用途，配置描述，充分叙述清楚，离开也要体面潇洒的离开。

  示例：
  

• 代码重要模块功能概述；

  用途： 重要模块肯定流着我们无数的汗水，我们必须得把他的精华仔仔细细、认认真真的告诉别人，事了拂衣去，深藏身与名！

• 项目中有是否依赖其他项目功能，如有需叙述下相关使用的逻辑；

  用途： 这个也是防止接手同事踩坑的好东西，当我们项目或者依赖引用了其他的项目的功能or接口之类的，万一依赖的项目出现问题，接手人员无法及时排查出问题。

• 项目代码版本、分支、提交规范及策略；

  用途： 项目版本如何管理，不同分支的作用、commit提交是否有固定格式，这个也需要标注清楚，以防止接手人员在你睡觉的时候打电话给你，告诉你哪哪哪哪有报错，需要你的协助。

• 项目代码构建打包方式、发布流程；

  用途： 让接手人员了解项目开发完成之后，如何构建打包？如何发布到test、uat、pro等环境；

交接清单（清新版）

辅助文档方面

• 项目代码地址；

• 项目接口文档地址；

• 项目UI设计稿/原型地址/项目历史需求列表文档；

• 项目历史需求列表文档；

• 项目现有问题/待优化问题；

• 目前是否有需要迭代的功能；

• 项目功能及作用；

• 当前项目可能关联人员

代码方面

• 项目代码目前技术栈、使用框架版本；
• 项目结构的整理文档；
• 代码重要模块功能概述；
• 项目代码版本、分支、提交规范及策略；
• 项目代码构建打包方式、发布的流程；
• 项目中有是否依赖其他项目功能，如有请叙述下相关使用的逻辑；

后序

我等采石之人，当心怀大教堂之愿景，在一个项目的总体结构之内，总有空间展示个性和匠心，，我们需要尽可能的把它描述的更加细致。

百年之后，我们的代码或许如今日的土建工程师看待中世纪大教堂建造者使用的技法一样陈旧，但是我们的匠心一定会得到尊重。

欢迎补充完善：点击这里提交PR