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】，让我们一起成长，谢谢。
微信公众号