1 前提技术

(1)工具使用

(2)基础技术知识点

  • MySQL
    • 分页:limit
    • 索引:index
    • 性能优化:select
    • 索引结构
    • 索引优化
  • Redis:
  • 计算机网络
    • 跨域cookie

    • HTTP

    • ssh密钥登录

      1
      2
      3
      $ ssh {username}@{ip_address}
      //比如:
      $ ssh root@192.168.10.128

2 心态

面对一个突如其来的bug,不应该过分焦灼与恐慌,正确的打开方式应该时沉着冷静,思考一会…,然后应该按照如下步骤进行推理:

  1. 针对一个bug,首先定位错误原因,大概估算出导致该bug的原因可能有哪几种,最好能够精确到小数点后1位小数
  2. 如果能够快速定位出导致bug的原因,那么说明你很厉害,然后你就可以按照梳理出来的几条思路进行查找bug原因
  3. 如果你还确定自己列出的导致的bug原因是否完全,那么没关系,大部分情况下的bug都是很难列出所有的原因,那么只能一步一步缩小问题的边界,就是排除一些不确定的因素,然后再进一步缩小问题的边界,如此循环几轮,bug原因应该就可以缩小到一个很小的范围

3 常见bug思路

一些线上发生的bug,很容易让我们头疼,因为某些线上问题很难在线下进行复现,那么就只能靠我们聪明的大脑在脑中进行“复现”了。但是,需要在脑中复现那些bug,其实是很难的,必须对这些代码了如指掌才能做到在脑中一个很清晰的复现,并一步一步通过在大脑中修改“参数”来“模拟”问题出现的原因,并最终解决问题。有以下几点思路可供参考:

  1. 找到一个非常小非常小的可以让你的程序出错的数据。比如空数组,空串,1-5个数的数组,一个字符的字符串。

  2. 在程序的若干位置输出一些中间结果。比如排序之后输出一下,看看是不是真的按照你所想的顺序排序的。这样可以定位到程序出错的部分。

    依赖于IDE的断点调试,是十分浪费时间的一种调试方法。而且在面试中,你是基本没有断点调试的机会的(因为很多公司是白板写题,不会提供给你IDE)。事实上在实际的工作中,你也很少能够有机会去进行断点调试,比如你进行的是 Web 开发,你只能想方设法的在代码中打印一些 Log,然后根据 Log 去分析出错的原因。你平时用 IDE 写代码,就十分容易养成这种断点调试的“坏习惯”。一个更好的方式,是使用打印中间结果的方式。

  3. 一行一行改成参考程序

  4. 定位了出错的部分之后,查看自己的程序该部分的逻辑是否有错。

  5. 给小熊讲程序

    可以放一只 “小熊” 在你的电脑旁边,一旦程序出错了。就对着这只小熊讲你的整个代码是怎么解决问题的。因为是给小熊讲,所以你可以把它当作什么都不懂,于是需要更加仔细的去讲述你代码中每个细节,所以你需要一行一行的讲,甚至连为什么你要用 ArrayList 而不用 int[] 都要讲得清清楚楚。讲着讲着,你就有可能突然发现你的错误所在了。

    这个技巧的意义在于,你在写代码的时候,脑子里可能想着一个事情,但是打出来的代码,可能是另外一回事儿。或者你脑子里想着有3个条件需要判断,但是打的时候,漏掉了一个。当你把代码重新讲一遍的时候,事实上是在重新整理你的逻辑,查漏补缺。这样很容易就能够发现你的错误。

  6. 查日志,很多人会忽略日志的作用,日志是不会说话的史官,忠诚地记录所有问题,通过查看日志就能迅速定位一些bug的所在;

  7. 网络抓包等方法

Reference

写在最后

欢迎大家关注鄙人的公众号【麦田里的守望者zhg】,让我们一起成长,谢谢。
微信公众号