大家怎么看待自己写的 bug

这个 Bug 是哪个傻 X 写的，一看是自己。

在注意力不集中，被多种事情骚扰的时候，低级 bug 会指数增长。。。

终于找到和我一样的小伙伴了（泪目）。
我实习那会每次上线都会有 bug ，而且都是很低级的， leader 拉到小黑屋谈过三次，甚至怀疑自己不适合干这行。
我的解决办法就是下次开发时仔细些，有 bug 就改，平常心~

@jorneyr 真实。。。回看自己写的代码会觉得怎么这么傻 x

正常看待，有 bug 很正常，谁能没有 bug

怪测试就完事了

这不怪测试

要是开发能避免 BUG ，那还要 Review 和 Tests 干嘛？

工程规范的每一步都有它的价值，职能不完整，就不能以工程标准来要求产品

有 BUG 是很正常的，BUG 能尽早发现是好事
每多些一行代码，就增加一点出 BUG 的可能性

低级 BUG 多是因为没写测试，或者没自测导致的吧

无比正常啊。有就改呗，不然测试就失业了

避免低级的 bug 就要自测，很重要，自测都通不过怎么交付上线

前后端对接接口的时候总要随便点点的

有些低级 bug 是自己代码习惯不好，自测不完善导致的，有些 null 等，idea 或者某些代码审查工具也会有提示。
如果 IDE 有告警提示，最好看一下，确定没有问题后可以不管，不确定的要明确下为什么会出现告警

自测一遍。

有点嗨的时候写的 code 之后看不懂，但觉得很高级，思路很精妙

低级 bug 大多能用测试覆盖抓出来。复杂的逻辑 bug 出一两个情有可原。
（写 bug 久了以后遇到大改动上线却许久不见事故单时甚至会以为没部署成功（

先自测，如果没时间写单测。用 postman 之类的点点吧

只要上线前把问题解决了就好啊，没 bug 后期的工作量怎么来，周报怎么写什么啊

写单元测试降低低级 BUG

焯！

学会了 举一反三 尽量不犯第二次错误

哦，那可真蠢 QAQ

人不是机器，是个人都会写出 bug ，你可能只是某段时间状态不太稳定而已，让自己放松一下，调整一下就好

自信的看，我从来不写 bug ，只写 feature 。

还是要学会写单元测试，不是盲目的覆盖分支
自己写的要有大概那部分会有问题的感觉，在那部分着重测试

自己生的自己养，好好照顾。

看代码：这块逻辑稀烂，我一定要查下 git 记录看看是哪个憨批写的
打开 Git：哦是我啊，那没事了

避免低级 bug ，只能写好测试了。
单元测试能大大降低低级 bug

傻逼竟是我自己

只能自测+自 review 了，之前 in 查询传了空列表进去报错，被测试提了几次 bug ，现在每个 in 查询都要 review 一遍看看有没有判空

赶进度的时候确实很容易出 bug

真想时间倒流…………

自己这几天状态就很差

反思，这就是经验，写着就觉得不对劲才对

楼主是不是写 python 的，用了 sqlalchemy...

我之前也是，后来去写 Java 了，好了很多

@zmxnv123 然而我就是写 Java 的。。。

多弄几次重大事故，就长记性了

许多次 bug 复盘后，我把墨菲定律奉为宇宙第一公理。

这种解决办法很简单，写单元测试就行了；用流程处理低级错误

写代码的时候可能忘带脑子了

嗯~ 蛮好的！成长的记录。

这 TM 哪个傻..是我啊..那没事了

有 bug：我真棒，只是是个正常人

多了解和思考业务，尤其是思考这一点很重要，把公司的业务烂熟于心，最好有时间多学学产品相关的课程。

我不写 bug 的话，那测试人员不就失业了吗？当前就业形势那么严峻，能多创造一些就业岗位，不是利国利民的事情吗？

null 和类型写错是语言问题

自己的屁股自己擦，写了代码多自测，多熟悉下业务

有敢写完代码不测的就提交的吗，估计没有吧，自己多测测就行了，极端条件多来几次

write test case

所以好的 IDE 带静态检查，不忽略警告，低级错误就少很多。

null bug 很常见，但是能上线说明流程有问题。一般 unit test 就能测出，然后是 code review ，最后 staging 测试基本都能排除了。

我觉得低级 bug 不可怕，因为容易排查。那些高级 bug 才是要了命，动不动来个 race condition ，deadlock 这些，平时屁事没有，关键时刻逢年过节流量一上来就崩，这才搞心态。

TDD 了解下

以前写过一个 bug 。有个傻叉，叫嚣个不停。但领导说了一句话。多做多错。同样的事情，不同的立场和说法。
前者调动你的积极性，后者打击你的积极性。有勇气和信心去解决，而不是愧疚和自责。

心态，这个词。真是妙呀。

自测，来不及就不测了

自测+codereview+测试部门测，再出 bug 就很平常心了，大家都说没 bug 啊。。。

做好自测非常重要，排期的时候时间排宽裕一点

业务 bug 没啥好说的，代码 bug 自己找找原因吧

没有过开发预留自测时间

为了测试有工作，我容易么我

where 漏写，要素察觉 难道是 delete from ***漏写

我的低级 bug 大部分都是测试用例跟测试找出来的。

给测试留口饭吃。

错误和 bug 没有勇气接受，这是祖祖辈辈和几十年的教育教给你的。

改改 bug, 喝喝水，上上厕所，提交 svn

吸取教训呗

严重吗? 不严重你喊个鸡儿!
严重吗? 哎, 难免会有些 BUG 的...

写出 bug 的我是傻逼。

有测试的话，就简单自测主要逻辑，然后交给 QA 测，有时候状态不好，能让他测出来一堆 bug ，修着修着，代码就走样了，有时候上线了也不安心。
没 QA 就要全部自测。自测完还出问题的功能，一般情况是漏掉某些条件分支的处理，十分钟内查日志修 bug 重新发版，快得很。

出了 bug 就改呗，不然还能咋样啊

出事前：sb
出事后发现是自已：正常

我一般，请测试同学喝咖啡，并表示，每找出几个 Bug ，我就请你喝一杯咖啡，你打我脸越狠我越开心。
当然，自己也要认真自测，反复自测。

自己能力有限，就求助更专业的同事协助（比如测试同学），慢慢培养好习惯了，Bug 就少了。当然，提测前 IDE 的检测必不可少。

看看有什么规范吧，尽量按照规范来，还有一个就是多写单测

遇到问题正视起来，想想以后如何保证不犯类似的错误

说明自测没做到位呗

bug 是不存在的，你看到的是我的 feature ，和预期不一致是你使用方法不对。

子曰：人非圣贤，谁能无 bug

因为写失误的低级 bug 都配叫 bug ，单测覆盖好，很难出现的吧。

@eason1874 你要累死 review 的人嘛，review 是不会关注低级 bug 的。至于功能的 bug ，业务逻辑的 bug 这个可以找测试兜底。至于代码实现的 bug 就是程序员本身主要责任，这个锅甩不掉的。

@Brentwans #78 单元测试当然是同样需要的，我说的 tests 包括单元测试，没有让 review 来负责这块的意思。我们的看法一致

这是我写的？？？？