不管是前端代码迁移还是后端代码迁移或者从一个地方拷贝到另外一个地方用，感觉回归工作量好大，而且太多细节，虽然有接口自动化，那也只能保障接口层面，而且对结果的断言也不是全量，就检验了状态和个别长度，而且前端的质量保证不了，只能手工全点一遍，感觉每次都是没有目标的全量回归，和盲测一样，开发还给不出影响范围，感觉开发自己写单元测试是不是可以保障质量
去年做了大半年的系统重构工作。迁移了大量的代码。涉及到几百个文件，接口数特别多。
我当时是在开发前列出了需要修改的所有接口。然后改一个，就查好所有的调用点，并且列好影响范围。
半年后提测。一个接口测试只需要覆盖一个调用点功能就可以了。最后顺利上线了
软件的一切问题归根到底都是跟业务有关。
1.业务角度
1）如果是简单的业务系统，也不涉及到数据安全和资金安全问题，在原有系统未出现重大漏洞的前提下进行迁移，并不需要做全量
2）只要是涉及资金交易或者数据安全的系统，任何情况下都需要做全量，严谨的态度可以避免重大的损失
3）在老业务系统基础上做新业务，基础功能必须做全量，避免新业务使用老业务基础功能时出现问题
2.技术角度
1）全量费时费力费心，但也可以让团队人员整体性的理解系统
2）如果开发人员代码严谨，团队工作安排有条理，只需要做核心功能或者基础功能的测试
3）全量是锻炼新手测试的好方法
3.人员角度
1）没有一个测试想做全量，因为人的心理状态是“这个东西一直都没有问题，为什么还要测试浪费时间？”，这是一种侥幸心理，只要有一次成功了，就会被侥幸心理支配。
2）任何团队也不能保证每个开发人员的代码质量和水平，即使是大厂，也有浑水摸鱼的人，没有人会真的做到逐行检查代码，总有偷懒和取巧的时候，这也是为什么有些时候功能做了，但上线没多久就出问题
3）人无完人，再强大的大佬也有犯错的时候，再没有必要的测试也有存在的必要
4.总结
1）最终的决定权永远在上层手中
2）可以结合自身经验提出建议，但要做好承担后果的准备，也就说要有足够的自信
3）决定下来的事先去完成，再去思考
回归是要做的，但没有目标的全量回归是没必要的。
标准的流程的话
评估影响范围这个再修改代码前就要做，
评估影响范围评估完后，修改代码和准备测试是同步进行的。
但大部分工程都没有按照标准流程走，事后进行质量保证的话，只能和开发取沟通影响范围了。
沟通不成那只能全量回归了。
全量回归做不好，那结果自然是质量不保了。
所以，建议评估影响完再开始修代码。
建议你采用git仓库或svn仓库存放代码。。。