互联天下，移动为王。曾经一度也做过移动APP的后端开发，根据自己的一些经验，谈一谈后端API接口的开发流程与环境的关系。
01 后端三个环境
一、开发环境
通常是api开发人员的自己机器，一般的作法是每个开发人员自己有一个环境，也有几个开发人员共用一个开发环境的情况。
开发环境的优势：
1. 程序员在自己的环境，有自己熟悉的开发工具或者IDE，有自己熟悉的调试工具或者流程，遇到问题能以自己熟悉的方式很快找到问题并解决。
2. 另外一个因素，恐怕是网络的影响了。在自己本机开发与调试，基本不受网络影响。如果是直接在测试环境（通常在远程）进行开发，公司网络大家用，总有那么一些时间，会出现打一个字符卡一下的情况，这样根本无法进行有效的编码。
开发环境的劣势：
1. 需要自己搭建一个和测试环境、生产环境几乎一致的环境，包括各种依赖包。但这对一个程序员来说，应该不是问题。况且，一个程序员连环境都配置不好，那么，他一定不是一个合格的程序员。
2. 需要同步数据库，这个比较麻烦，因为很多情况需要数据支持才能进行开发与调试。通常可定期或者在需要的时候，同步一份测试环境的数据库下来，本地还原数据。在偶尔的情况，也可以直接去连接测试环境的数据库。
二、测试环境
通常是程序员开发完成后，完成了由开发人员的自测，包括单元测试后，将代码更新到测试环境，交由测试人员进行测试。
如果测试人员测出了问题，这通常有以下几种情况：
1. 确实是程序员导致的bug，需要由程序员修复。此时，程序员会将发现的问题，再在本地开发环境进行跟踪（一般这比在测试环境快），一旦找到问题并修复，再将代码更新到测试环境，由测试人员进行确认。如果还有问题，重复这个步骤。
2. 如果是测试人员和开发人员对问题的理解不同造成的，这个时候应该对照需求进行讨论。如果是程序员的问题，继续回到步骤1进行。如果是测试人员的问题，由测试人员自己记录并保持代码不变。
3. 由于开发人员的环境或者数据库与测试环境不一致导致的问题（开发环境没有问题，测试环境却有问题），此时，可以直接修正开发人员的本地环境，或者直接修正测试环境（有可能是测试环境需要更新等）。
4. 通常情况，开发人员是不会在测试环境修改任何东西的，即使直接修改测试环境，通常也只是针对一些特定的bug（本地无法重现的）进行一定的跟踪与调试，最多加入一些日志信息或者临时修改部分代码。如果在测试环境修改代码后，问题解决。开发人员还是得在本地再按同样的方法修改，改好后又同步一次。为什么每次都得强调在本地修改一次，这是版本管理的一个重要概念，本地需要对代码的所有修改进行跟踪，最终的所有修改都能在git等版本管理里面能跟踪的。
如果测试人员没有测试出问题，即确认满足了已知的问题。此时进入发布阶段。
三、生产环境
通常是测试人员确认了在测试环境的所有代码后，即可直接发布到生产环境。
发布到生产环境后，还是可能会出问题，发现了bug，bug通常有几种：
1. 由测试不全面导致的，即在测试环境没有测试到的bug，也意味着这个bug在测试环境同样存在，这个应该由测试人员来负责找到问题并告诉开发人员修复。如果要定责，也应该是测试人员的责任。当然，有些bug也是由数据量导致的，测试环境毕竟数据量不够，可能在生产环境的某个用户会出现问题，而测试环境根本没有这个用户。
2. 由于测试环境与生产不一致导致的，需要让测试环境与生产环境一致，如果还有问题，也需要记录，每次发布是否要作特殊的操作。
3. 在生产环境发现的任何问题，需要与测试环境进行对比，是否测试环境也同样有这个问题，是否这个问题是开发人员导致的问题，如果是开发人员的问题，又需要从：开发-测试-生产这个流程来走，是不能在生产环境直接进行修改的。
修改生产环境的任何一行代码，都可能会影响到用户。没有任何人敢保证当前这行代码不会影响用户的使用。软件由代码组成，每一行代码可能都会影响一个因素。
02 客户端三个版本
依照上面的三个环境的情况来，开发人员需要有每个客户端更新版本的三个环境版本：
ios客户端：
开发版本
测试版本
生产版本
android客户端:
开发版本
测试版本
生产版本
最严格的来说，任何客户端更新后（哪怕只是修复一个小bug），都应该同时发这版本的：开发、测试、生产三个环境版本给开发人员，否则，会出现的问题：
1. 只发测试版本，然后说服务端有哪些问题需要修正，这就很明显了，要求服务端开发人员直接去测试环境跟踪问题，并修复。这个明显不是最好的方式，而且修改的代码不能很好的进行本地代码版本管理。
2. 只发生产版本，这就更有问题了，生产环境上面是不能修改任何代码的。
原因很简单，开发人员需要在本地跟踪问题，发现问题，并最后修复问题。这些全部是在本地进行的，完成后再更新到测试环境测试，由测试人员确认后再更新到生产环境。
除了本地无法重现bug这唯一的特殊情况，需要去测试环境进行跟踪与调试外，不得上测试环境改任何代码。陈了测试环境无法重现bug这唯一的特殊情况，需要去生产环境进行跟踪与调试外，不得上生产环境改任何代码。
03 流程与需求管理
开发流程还和需求管理有很大的关系，这个本身算是单独一个主题了，在此，只简单说说：
首先，需要明确，哪些是bug，哪些是新功能。这个bug，是在哪个环境有（测试还是生产）？还是都有？这到底是一个bug，还是一个新功能。不能上了生产环境，才发现一个本来是新功能但没有做，但却告诉开发人员这是一个bug。这是不合理的。
其次，这个bug是什么时候导致的？不能因为以前没有测出来的bug，硬说成是新修改导致的bug。代码是可跟踪的，bug也需要可以跟踪。这个版本，需要开发人员解决哪些bug，添加哪些新功能，都是要明确的。需要在第一阶段一起提出来。