程序员如何减少bug？

程序员(开发)如何减少bug？

程序员多看error日志，能减少bug

开发多看error日志，能够减少bug。测试有时发现不了一些代码类的异常bug，比如空指针、数组越界之类的异常。
开发不仅要看日志，最好还要多看测试环境的error日志，多看生产环境的error日志。

程序员对着测试用例自测

开发人员都知道要自测，但是大多数都不知道如何有效地自测。很多程序员都是把代码更新到测试环境后，随手点几下，想到哪就点到哪。
有些甚至只在开发环境自测，没有到测试环境去自测。这样的自测明显是不够严谨的，还是会有不少bug，最好是在测试环境对着测试用例自测。
程序员(开发)对着测试用例自测，能够有效地减少bug。
测试同学写的测试用例，绝对是比开发人员乱点更加严谨的，覆盖率也会更广。

开发自测减少bug的流程

• 开发评估工作量时，要多留1天的时间自测
  对着测试用例自测，是会比普通的自测费时间的。毕竟测试用例的内容会比较多。

• 必须评审测试用例
  测试用例必须评审。评审测试用例，能够加深开发和测试对需求的理解，让开发和测试对需求的理解与产品同学更加接近。三方达成共识，是最好的。
  评审测试用例的过程中，开发会对需求的理解更加深入，能减少踩坑，避免方向错误，做了不必要的或者错误的需求。

• 产品最好参与评审测试用例
  产品经理不参与评审，那么只有开发与测试达成共识，还是有可能偏离产品规划的需求。

• 测试人员最好在提测的前两天评审测试用例
  如果是在提测的前一天甚至当天评审，那开发人员就没有足够的时间自测了。
  评审过程中发现开发、测试、产品三方的分歧越大，开发需要修改的东西越多，花费的时间也越多。

• 开发人员要保持耐心
  对着测试用例自测，实际上也是不小的工作量，这个过程会有一点无聊，需要保持耐心。
  如果时间确实不多，至少主要的分支得自测过一遍。

开发对着测试用例自测的其他客观条件

• 团队必须要求测试写测试用例。。
  这个是一切的基础，如果测试不用写测试用例，那后续的工作无法展开。

• 团队不应该考核测试提出的bug数量
  如果考核测试提出了多少个bug，那么bug的数量关系着测试同学的利益。
  测试会反复地跟开发人员拉扯，有时会为了一个问题究竟是不是bug而争吵半天，这样是没有意义的。
  测试为了绩效，也是不会心甘情愿地交出测试用例的。