给软件治病

如果开发人员是医生，开发出来的软件是病人，bug是病菌
“软件怎么能成为病人呢？有病菌存在的软件，并且病菌会偶尔或者经常发作，那么这样的软件就可以称为病人吧。以如此的标准，除非hello world, 所有的软件都可以成为有病的软件了，借喻：病人”
如何给软件治病：就是查bug,消灭bug。
   1）常见的改bug方式属于头痛医头，脚痛医脚的方式，治标不治本。这一段时间头不痛了，但是过上一段时间，由于受到一些刺激，头痛的病可能又犯了。表现在一个bug好像被改正了，不会再出现了。但是并没有考虑到可能引起这个bug的各种情况，如果负载增加，运行时间变长，或者运行的环境改变，这个bug又会出现。更没有去寻找和这个bug相关的或者类似的bug,问题并没有彻底解决。如果增加新的模块，还会有类似的bug出现。。

   2）还有更差的方式，就是不但头没有医好，而且还引发了其他的病痛。头更痛了，而且脚也出了问题。这就是我们常见的，改bug的时候，结果引入了新的bug.改bug的时候，直接拷贝粘贴，结果把病毒也带来了。或者某个全局变量没有搞清楚，改写了以后影响了其他的模块，或者某个文件取错了版本，这真是一件痛苦的事情.越改越问题越多.越改越烦，最后就是彻底放弃了。

   3）还有更痛苦的事情就是，把病人的需要搞错了，本来是头痛，结果头痛当脚痛来治。这就叫花钱买罪受，越治越差！只能说需求分析太重要了，和用户的沟通太重要了！要避免这种情况，就要和用户有很好的沟通，并且经常询问，调查用户的反应，及时得到用户的反馈。关于需求的话题以后有机会再详细展开讨论。


   4) 最好的情况就是，标本兼治：找到头痛的根本原因，不仅仅把头痛的毛病彻底医好了，而且在治病的同时还增强了身体的抵抗力，或者顺便把脚痛也医好了。

  
  如何避免第二种情况，如何做到第四种情况？
  第一个药方是：组织对bug修改进行review+单元测试
       对bug修改进行review其实就是一个局部的有针对性地复查，比如做个CT之类。
       “单元测试可能不能用在人身上，难道可以在人身上打个桩？或许这是医学事业的伟大发明也不一定哦！”

  第二个药方式：在改bug的同时进行重构+review+单元测试
       重构就是增强身体免疫力，例如组织再生，加强锻炼，注意饮食，使得身体的营养成分更加均衡。

  第三个药方是：code review+重构+单元测试
       code review就好像是一年一度的全身性的体检，如果身体健康状况不是很理想，那么一年两次体检也未尝不可。考驾照，换工作，都要体检呢！尽早查出问题，尽早治疗，花钱少，效果好。