封版之夜战斗札记

本文主要是介绍封版之夜战斗札记，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

来公司也一年了，项目从早期不断迭代，到最近临近交付客户。有很多值得反思和记忆的故事，我明显感受到了自己的成长，也明白了产品、研发的重要。

昨晚是封版本的最后一晚，一直加班到了凌晨2点。从晚上开会到不断修复紧急bug，每个小伙伴们都绷紧了神经，全力以赴地验证所有的case。最终还是如期交付，但值得思考的问题不少。如果我不写下这些，我怕忙碌会把这些经验湮没。

1. 需求是产品之源，必须深刻理解。

如果有不清楚的地方，在开发之初就应该提出疑问，通过一次一次产品研讨，弄清楚所有逻辑。

打个比方，一款银行理财产品，用户下单购买该产品后，进行作废订单，到底如何处理库存和销量等等。这些看起来简单的问题，对不同的用户可能选择不同。有的银行认为销量是需要计算真正成交的订单数，如果作废，则需要从总销量里面去掉被作废的。有的银行则认为只要成交过，那么就持续累积。

对于研发工程师，对于这些可以有自己的见解，但不能直接替客户做选择。倾听客户的真正的心声，才能实现真正有价值且符合需求的功能和产品。

2. 全局检查，深入所有逻辑分支

不得不相信一句话：任何可能出现的问题的地方，都有可能出现问题。所以每次修复bug的时候，一定要从全局去思考，是否有关联性的逻辑已经检查了，确保算无遗策。

3. 学会跳出常规思路去用产品

在使用产品进行测试的时候，我们不能只想着怎么正常用这个产品，而是要尽量从各种情况去玩整个系统。摆脱一种产品标准使用方式的思维定势，像折腾手办一样，把它扭成一个意想不到的形状和方向，然后看它还能否正常还原。如果只是顺着期待的结果去准备数据，去测试常规的case，我们很难真正了解一个产品的潜在问题。就像如果一直不敢下水，虽然不会被淹死，但是很难真正学会拥有。

4. debug也是需要准备的

之前老板就提醒过几次，准备好一些query和一些排查工具，方便在最终测试里面遇到问题的时候能快速排查数据。我对我们开发的系统过于自信了，并没有专门准备query。在连续发现一些异常数据的时候，临时再去写sql，有些慌忙。提前准备能让自己更从容，也能更快定位问题，减少不必要的debug时间。

现在已经走出了一百步，也要走向真正的世界，希望轻舟一过，山也向后，我更向前。

这篇关于封版之夜战斗札记的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！