程序员(开发)如何减少bug？
程序员多看error日志，能减少bug
开发多看error日志，能够减少bug。测试有时发现不了一些代码类的异常bug，比如空指针、数组越界之类的异常。
开发不仅要看日志，最好还要多看测试环境的error日志，多看生产环境的error日志。
程序员对着测试用例自测
开发人员都知道要自测，但是大多数都不知道如何有效地自测。很多程序员都是把代码更新到测试环境后，随手点几下，想到哪就点到哪。
有些甚至只在开发环境自测，没有到测试环境去自测。这样的自测明显是不够严谨的，还是会有不少bug，最好是在测试环境对着测试用例自测。
程序员(开发)对着测试用例自测，能够有效地减少bug。
测试同学写的测试用例，绝对是比开发人员乱点更加严谨的，覆盖率也会更广。
开发自测减少bug的流程
-
开发评估工作量时，要多留1天的时间自测
对着测试用例自测，是会比普通的自测费时间的。毕竟测试用例的内容会比较多。 -
必须评审测试用例
测试用例必须评审。评审测试用例，能够加深开发和测试对需求的理解，让开发和测试对需求的理解与产品同学更加接近。三方达成共识，是最好的。
评审测试用例的过程中，开发会对需求的理解更加深入，能减少踩坑，避免方向错误，做了不必要的或者错误的需求。 -
产品最好参与评审测试用例
产品经理不参与评审，那么只有开发与测试达成共识，还是有可能偏离产品规划的需求。 -
测试人员最好在提测的前两天评审测试用例
如果是在提测的前一天甚至当天评审，那开发人员就没有足够的时间自测了。
评审过程中发现开发、测试、产品三方的分歧越大，开发需要修改的东西越多，花费的时间也越多。 -
开发人员要保持耐心
对着测试用例自测，实际上也是不小的工作量，这个过程会有一点无聊，需要保持耐心。
如果时间确实不多，至少主要的分支得自测过一遍。
开发对着测试用例自测的其他客观条件
-
团队必须要求测试写测试用例。。
这个是一切的基础，如果测试不用写测试用例，那后续的工作无法展开。 -
团队不应该考核测试提出的bug数量
如果考核测试提出了多少个bug，那么bug的数量关系着测试同学的利益。
测试会反复地跟开发人员拉扯，有时会为了一个问题究竟是不是bug而争吵半天，这样是没有意义的。
测试为了绩效，也是不会心甘情愿地交出测试用例的。