5.4 代码检查，自己开发的代码，基本上很难发现其中的问题，即时找到相应人帮忙检查代码，是比较好的解决代码问题的方案。其实，在给别人检查的时候，也是自己检查的时候，相当于自己再一次的开发，也能及时发现问题。

6. 多轮的测试验证

6.1 测试同学，其实在开发快结束的时候，已经把测试用例给到大家。这也是另一个角度的开发，因此，参考测试用例进行相应开发修改也是很有必要的。

6.2 第一轮测试，可能主要是大功能的验证，小功能的检查，挡板环境即可，无需真实环境。

6.3 第二轮测试，则是要把之前的测试及各种配置，全部清空，以一个全新的项目来对待，重新进行相应环境搭建，代码部署，然后再进行测试，确保问题解决后，做好了相应的处理方案备份。这时，就需要用到真实的应用环境了。对之前一些暂未解决的问题进行重新测试。确保无问题。

6.4 第三轮测试，应该是一个灰度发布的环境，也可以认为是预上线。将所有环境当作是线上来处理，如果运行ok,即可准备发布上线了。

6.5 在测试过程中，因测试人员只是人工的处理，有时不一定能捕获所有的问题，开发在这时，也应站在测试的角度，发现问题，即时监控，即时处理。

6.6 自动化测试，这个其实应该是靠后的处理，但是如果能做到这些的话，也能够快速的重现问题。

6.7 压力测试，应对线上环境，需有一定的能力评估，不然，只瞎猜，恐怕也不是好事。随时准备横向扩展，也只是出现问题后的解决方案。做好压测，发现代码中存在的问题，即时处理掉。

7. 外围处理(上线前)

7.1 上线前，肯定是有很多事务要处理的。

• 测试环境中的各种基础数据，随时导出备份，到线上时，直接插入使用；
• 服务器，在架构评审过程中进行数量评估；
• 域名，对外网提供服务一定是要域名的；
• 权限，比如上线后，出现了问题，谁有权限来处理问题，一定提前给到；
• 验收，这是关键的一点，功能完成后，及时验收，如果上线有些小问题，尽量协商，不要在线上频繁改动。

如此！

整个项目就完工了。

其实发现，一个项目真正的功能实现，并没有占多大的比例，而是一些前期的准备及后续的处理，反而占了更多的时间。

第一个版本上线后，可能接着就是迅速迭代了。（如果运营还可以的话！）

以上，就是一整个项目的流程清单，以一步一个脚印的经历总结，不涉及具体语言代码，但是思路都是相通的，希望对你有帮助！