Java教程

封版之夜战斗札记

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

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

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

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

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

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

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

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

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

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

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

4. debug也是需要准备的

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

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

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