前言
项目交接文档，应从项目立项之初就可以开始写。
而不是等到项目交接时才写。
因为那时写，已错过很多细节。
这些细节可能是高质量交接的关键。
业务理解
理解业务的基础上，对于需求的实现或bug修复，做出的技术判断，坑更少。
可以知道需求合理性，需求实现的难度，需求实现的可扩展性。
必要的地址
前端代码托管地址
现在一般用GIT来对前端代码做版本控制。
大公司一般自己内部搭建gitlab系统。
小公司基本购买私有git库。比如conding.net，github私有仓库。后端代码托管地址
老项目，老后端不二话，SVN。
潮一点，GIT。视觉稿/交互稿地址
老早以前视觉稿是PSD。
现在老早是Sketch，再通过Marketch来导出带有标注信息的稿子。
接口定义
除了接口地址，就是返回格式定义了。
正常有数据返回
{
content: {},
success: true,
errorCode:"",
errorMsg: "",
csrfToken:"", // 防伪造请求
}
正常空数据返回
{
content:null,
success: true,
errorCode:"",
errorMsg: "",
csrfToken:"",
}
异常数据返回
{
content:null,
success: false,
errorCode:"E404",
errorMsg: "Interface not found!",
csrfToken:"",
}
- 日常测试地址，预发地址，线上地址
三者环境的区别另说。
项目管理系统地址
业务或者产品提出的需求列表（需求的时间，描述，完成情况）
测试或者他人提出的bug列表（bug出来的时间，描述，完成情况）
构建打包方式
我们知道seajs，requirejs，backbone，angularJS，ReactJS组织代码的方式各不同。
我们还知道grunt，gulp，webpack打包配置方式不一样。
还需去各自官网理解框架和打包的使用方式。
调试方式
调试方式也因项目而异。
一般来说线上运行的代码都是压缩混淆过，然后代理到本地对应的inline-source-map文件即可调试。
JavaScript Source Map相关信息，
可参考阮一峰文章JavaScript Source Map 详解
webpack文档Webpack devtool
代码版本控制策略
基本上有个日常开发分支，线上发布分支。
commit信息提交规范。
