gpt4 book ai didi

封版之夜战斗札记

转载 作者:我是一只小鸟 更新时间:2023-04-30 06:31:09 34 4
gpt4 key购买 nike

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

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

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

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

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

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

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

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

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

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

4. debug也是需要准备的 。

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

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

最后此篇关于封版之夜战斗札记的文章就讲到这里了,如果你想了解更多关于封版之夜战斗札记的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。

34 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com