5

封版之夜战斗札记 - freephp

 1 year ago
source link: https://www.cnblogs.com/freephp/p/17364727.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

封版之夜战斗札记

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

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

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

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

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

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

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

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

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

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

4. debug也是需要准备的

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

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


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK