脚踏实地

bug的起源: 1945年，一只小飞蛾钻进了计算机电路里，导致系统无法工作，一位名叫格蕾丝·赫柏的人把飞蛾拍死在工作日志上，写道：就是这个 bug(虫子)，害我们今天的工作无法完成——于是，bug一词成了电脑系统程序的专业术语，形容那些系统中的缺陷或问题。

bug一词在程序员看来，是指“故障”、“缺陷”。了解软件开发的朋友都非常熟悉，程序员和测试人员更不用说，在工作中会常遇到。 作为一名开发人员，项目出现bug是避免不了的。无论你是一名初入职场的小白，还是拥有经验丰富的大佬，只要经常写代码，很难不出bug。正所谓常在河边走，哪能不湿鞋。 记得以前经常听人说，如果你没有把系统搞宕机过，就不是一名合格的CTO，成为一名出色的开发人员，经验都是一个一个积累起来的。

其实在我来看，所谓的bug指的是生产环境发现的问题。那么只要线上不发现问题，那就不是bug。 之所以这么讲是因为一旦影响程序的正常使用便会影响公司的利益，公司利益被影响你自己的利益也会受影响。所以为了自己写程序的时候尽量多测试，将可能会应对到的情况想得全一点，减少bug的出现。

程序员能为了减少bug的出现能做的可以从代码方面下手:

• 在正式开发前，做好准备工作，先梳理一下业务逻辑，根据业务场景可以使用什么设计模式，是否需要缓存，列一下需要用到的框架等，尽量考虑的全面一些，考虑一下不同的情况。
• 在编写代码的时候需要注意以下几点，供参考：
  1. 在关键的地方写注释，标注一些关键的信息；
  2. 增加校验;如: 调用第三方程序或者使用一些中间件的时候，拿到结果不要着急使用，先做校验，这样可以很大程度上避免NPE的出现；
  3. 当在程序某个功能下加一个非堵塞性功能的时候，需要考虑是否会影响到主流程的使用，有时候可能不经意的一个问题会将它的影响无限放大，随之而来的就是用户投诉，老板亏钱；
  4. 当编写代码的时候尽量写一些简洁，清晰的代码，比如一个方法实现的功能较多，应把它拆开。如果代码变得易于维护起来那么bug的数量也会大大降低；
  5. 尽量编写一些能测试的代码，将一个方法的职责做到最小，一个方法就干一件事情；
  6. 当开发功能完成之后不要着急测试，先自己审查一下代码，确认哪些地方可以进行优化，之后再调试功能进行单元测试；
• 当开发完成之后一定要进行单元测试，这可以大大降低bug的数量。测试的时候需要模拟线上的环境数据来测试新增或修复的功能，否则即使改完功能，可能也会由于请求次数或数据量巨大问题导致功能不能使用。

除此之外，一方面可以借助一些工具来进行bug的规避，比如sonar，可以发现一些潜在的错误和问题。另一方面我们要不断学习和提高自己的编程技能，来提高代码质量和减少错误的发生。

但是尽管这样，bug这种东西还是不可避免的，我们只能减少bug而不能消除bug，没有人保证自己的程序一定是没有问题的。 为了减少bug我们只能多测多验证，哪怕单元测试通过都不能非常有效减少bug，因为受到写单元测试的人的思维角度限制，导致单元测试的片面性。

其实最容易出现的bug是逻辑上的bug，如复杂庞大一点软件如果不是所有地方都熟悉就写代码是比较容易遗漏一些特殊情况的。 除了逻辑上的bug外，在开发中还有框架中存在的bug，但是这种bug是我们避免不了的，如2021年爆发的log4j堪称史诗级的bug。 没什么好的办法可以提前避免掉，就多用一些稳定的框架吧，有apache就用apache，没有就优先使用fork、start高的框架，从概率上减少。

一个人的力量毕竟有限，必要的时候可以叫上同事，进行code review。

因为bug是不可避免的，所以解决bug能力就显得尤为重要，程序员归根到底拼的是解决问题的能力。我总结了一些bug的解决思路，供参考：

• 确认bug的存在，包括复现bug的步骤和现象；
• 分析bug的根本原因，找到导致bug的代码或逻辑，一般通过日志查看一些栈的信息；
• 修复bug的代码或逻辑，并重新测试确认修复成功；
• 编写针对bug的单元测试，验证bug是否修复；
• 记录bug修复的过程和结果，以备将来参考和验证；

亲自复现问题，关注第一现场，确定是必现还是偶现。要区分是人的问题还是环境的问题，如果是人的问题，那是配置参数的问题还是代码逻辑的问题。如果是配置参数的问题，那应该通过对比正常运行的配置参数发现问题。 如果是代码逻辑的问题，则通过git commit的历史二分查找缩小出现问题的逻辑范围。如果是机器的问题，确定是单机问题还是集群问题。如果是单机问题，则替换机器，如果是集群问题则考虑升级硬件设备。