项目版本上线，小鹿获得最佳 Bug 奖！

周末又到了，小鹿妹子爬上来又更篇水文了。这周似乎不一样，这周小鹿获得了一个最佳 Bug 奖，上图，咱们说说这个奖咋来的。

当你工作之后，有没有这么一种感受，改别人 bug 是多么痛的的一种领悟～。

1、

入职有一个多月了吧，即将迎来第一次项目的版本上线，挺期待的，期待的是项目上线后，能有多少 Bug，哈哈哈。

这一个多月一直在参与一个老项目上的版本迭代更新，基本都是在一些老代码上进行开发、完善新功能的。

说实话，项目确实挺有挑战性的，而且我蛮有兴趣把它做好。但是现实情况不如意呀，技术没啥特别大的问题，问题是业务理解不透彻呀，引发了各种各样的坑，导致出现了很多有趣的现象。

自己刨个坑，然后把它用土填埋上，突然你会发现身后惊现两个坑，没错，这两坑不是别的给你的，而是你刚刚在用土的时候自己刨的。然后你又想埋上这两个坑，可怕的是你身后会有四个坑......

嗯～，被经历毒打后，总结出最好的解决办法，就是不填坑，就静静的看着它，这样它永远在你心中只是一个坑。

嗯～，是不是很真实？

2、

进入主题，这次这个最佳 Bug 奖是自己“小鹿xxx工作室”颁发的，奖励给小鹿这次版本上线写的 Bug 最多，再接再厉，继续努力。

不忽悠你，有图有真相的那种，小二，上图。

鹿哥，你写的 Bug 好多呀，这还敢放出来，不怕我们嘲笑你。不瞒你说，你们如果笑了，那这图真值得一放，毕竟能供大家伙乐呵乐呵呢。

这时候老大看小鹿解决 Bug 表现的不错，再奖励你一个，"小鹿，这个 Bug 你再解决一下吧"，"好嘞～，分配给我吧～"。

老大对我可太好了，这画面，爱了，爱了，画面简直不敢想象！

那么，这个项目版本上线后，"Bug 小王子"这个称号非小鹿莫属了。有请 2020 届 9 月份获得 “Bug 最佳奖”获得者，上台领奖。

3、

玩归玩，闹归闹，别拿 Bug 开玩笑。说点正经的，很多 Bug 的产生呢，我总结了几点如下。

由于产品功能代码之间耦合性太强，导致了你修改了其中一段代码，其他联动的功能莫名的失去原有的逻辑，导致测试小姐姐二次测试会给你提交两个甚至更多的 Bug ，有点像细胞分裂。

作为开发人员，尤其是刚刚接触项目的开发者，在不熟悉业务以及代码的情况下，冒然的修改代码，大概率事件造成更多的 Bug，回头不用去试，小鹿已经帮你试过了，是很痛的一种领悟。

所以在和一些同事聊天中，表示发现问题，就是不敢下手去改，这.....

那么有人说了，那你多理解业务需求不就好了，最好的办法就是看需求文档。没错，这是我想到的第一个法子，当对于一个刚接触公司产品的小白来说，看需求文档就是看天书。

它不像以前自己开发的产品需求一样，开发这个功能是干嘛的，应该怎么去开发，以及用户体验如何提升，性能如何优化等很清晰。所以对于产品需求，还是需要靠长时间自己慢慢摸索的，这东西急不得。

4、

通过这段时间的工作体验，逐渐发现学历上带来的缺陷。鹿哥，学历咋和工作挂上钩了？不是学历面试才看重的嘛？

确实面试看重学历，也相信很多人和小鹿一样想过这个问题，现在学历低不用太在意，有能力就行了。现在突然发现这也算是一种浅层面的心灵鸡汤，为何这么说呢？

在做项目中，我发现自己又一个很大的毛病就是不细心，我反思这个问题出在了哪个环节，我觉得我这个毛病是在大学养成的，毕竟垃圾大学有垃圾大学的坏处，包括环境、周围的人，对你有很大的影响的。

没有人对你严格苛刻，自然而然自我处于一种放飞的状态，那天的一个 Bug 让我改到半夜了 12 点，当晚突然失眠了，最后文章都没来得及写就去提前休息了。

同一个问题代码，反复出现细节问题，那天晚上，提交了 N 次代码，每次都因为一些细节被老大打回。也可能那天，到了晚上消耗了一天的精力确实跟不上了，回来还要做饭写文的，毕竟人的精力有限嘛。

还有可能就是之前没有养成一种好的习惯，不止这次，每次我发现都会在一些小的点子上出现问题。往大了说，这将影响项目的一些问题，往小出说，这也是个人很不好的一个毛病。当然，有毛病就要改，不然以后吃亏的是自己。

小结

其实，最后自己想想，还真是这么回事。一些坏的习惯和毛病都是大学养成的，这种后知后觉，真的很难感知到。

而且市面上，很多人反应简历的一些细节问题，比如技术英文单词的拼写、没有留下手机方式、甚至没名字等问题。这种情况出现，不在少数人中，也恰恰反映了一种状况，值得我们每个人去反省。

真的，写完这篇总结深深的感受到，细节决定一个人的是非成败！

更多相关文章