我们为什么会引起bug？

     我们写程序，为什么总写出bug呢？有人说，没有bug程序员不就失业了吗！没有bug还要测试人员干啥！当然这只是玩笑话，但也侧面反应了bug和程序代码不能分割的关系，即使是一句非常简单的代码，也可能会在不同运行环境，不同编译条件等情况下产生bug，所以如果严谨的说一段程序没有bug，肯定要附加上某种条件，即在xx条件下，该段程序是没有bug的。
         虽然没有绝对的无bug程序，但是我们不能以此为理由，就认为程序员写出bug是天经地义，理所当然的。因为大部分bug都是沟通不到位，马虎大意，考虑不周等引起的，而非运行环境等客观因素导致。所以有必要分析一下bug产生的原因，以避免大部分bug的产生。以下是一些常见原因分析及对策：
        1）心流状态自作主张：程序员写代码有时会进入心流状态，这时候如果写到一段需求不清或逻辑矛盾时，往往会选择一个自己认为正确的逻辑写下去，或TODO一段注释，以防心流被打断，当然有些程序员也会立即去问产品策划，求证后继续写。
         2）心流状态被打断：程序员写代码正嗨时，忽然被别人打断或紧急处理一项其他任务，等再回来时，可能就会疏忽一些逻辑处理。
         3）马虎大意：写代码心不在焉，导致漏写，错写的发生。
         4）没有考虑边界情况：有些是需求边界文档中没有全部说明，而程序员又没考虑到。有些是程序角度的边界，如整型溢出，数组越界，属于数据类型没有选对。
         5）第三方库的bug：选择了不成熟的库，或不适应部署环境的库导致。
         以上几种情况中，马虎和沟通不到位都是可以尽量避免的，两者避免之后可以减少80%的bug，如何避免呢？我总结为二慢一快，即写代码前慢思考，写代码中快速实现，写代码后慢交付。
          首先，拿到一个需求时，先不要急于写代码，一定要把需求了解充分，把各种可能性想清楚，对需求中提到的，多质疑，对需求中未提到的多确认。需求想清楚后，在技术建模阶段，提炼出重点难点，考虑项目中是否有可复用的模块，重点难点有没有成熟的解决方案等，考虑清楚这些可以大概列出代码实现的先后顺序。
        然后，按分析好的需求和计划好的实现顺序开始码代码，这个阶段一定快速果断，切勿拖拉，一气呵成。中间如果不被打断那真是极好的。如此阶段拖拉或被打断时间很长，则一些思路就会连不上，要花费很多时间重新梳理，很容易遗忘一些情况，导致bug。
        最后，快速实现后，按需求把功能自己过一遍，查漏补缺，此阶段不用求快，有些程序员为了赶时间，快速交付，产生了bug，又回头修复，来回折腾，反而浪费了时间。还有些程序员写完就不管，交付测试，且不管代码写的好坏，这是一种不负责任的表现。
         以上马虎和沟通原因只要稍加注意，养成习惯，都能做的很好，其他情况的bug，有时是我们不可控的，那就遇到了分情况一一对应吧。
        关于bug，就先到此吧，希望bug能少些，工作更轻松些。