最近开发一个对于公司来说具有重要战略意义的app项目，我底下带了Android, iOS, 前端开发，后台开发的技术团队。项目进度很紧，人手不够，不断的小脚步迭代，快速前进。
众所周知，对于软件行业，只要是开发工作，永远都避免不了有bug的存在，有bug并不可怕，就怕你在代码的海洋中毫无方向的摸索，那简直就是噩梦！而我在带团队的过程中，常常发现属下经常面对稍微困难一点的bug时都无所适从，不知道从哪里下手，有的时候，问题居然就是出在少了一个括号，符号，逗号等等，而找我debug的时候却已经struggle了大半天了，非常伤脑筋，并且这种bug往往还不容易被发现。每次这个时候都会来找我，基本上无论多么复杂的bug，到我这里都能快速得到解决，枯木逢春！这并不是我运气好，而是在长达15年的软件开发经验过程中，我早已摸索了一套debug问题的方法论，只要按照这个步骤来，基本上就能快速定位问题具体出现在代码的哪一行，让bug原形毕露！因此，在遇到bug的时候，基本上能从容不迫。
我意识到，团队成员几乎没有一套方法来解决bug，而是完全凭着感觉在debug，这样运气的成分就非常大，不能从容不迫的解决问题，因此每次遇到bug的时候都心里没底，并且找到我的时候往往已经浪费了大量时间，在项目进度很紧的情况下，这是很揪心的一件事。所以，我专门针对整个团队做了一次如何debug问题的技术培训，经验证，下属后来很少再来“打扰”我了。
由于遇到bug一个常态，所以能够快速发现和fix bug是一个非常重要的工作技能，因为它不仅能提高你的工作效率，而且，将来妈妈再也不用担心我碰到“bug”了不是。因此，对于所有软件从业者来说，能够掌握这样一种方法是非常有意义的。这里，我就抛砖引玉，和大家分享一下，如果有什么好的意见，也请大家给我留言。
必要前提：
1. 你必须对你的代码工作/业务流程很熟悉，这个很容易理解，否则就成为无源之本。
2. bug必须能够重现，否则只能靠猜。所以在debug之前，必须确认这个bug能够通过某个步骤，每次都能够exactly发生。
好了，有了以上2个前提，下面在说说如何一步步debug：
1. 根据场景，你一定知道在代码都经过了哪些主分支。那么首先在大概出现问题上下游的主分支入口处(第一行代码处)加上log。
2. 重现bug，看log在哪2句之间出现了bug。
3. 在这2个log之间的分支处添加log，继续重现bug，周而复始，很快就能够把bug出现的地方夹逼到某一行。
4. 这个时候可以通过设置断点，重run代码，然后在此行附近观察变量的值是否符合预期，一般来说，会迅速找到问题所在，比如某个变量的值不对。这个时候一个线索就找到了，然后就可以逆流而上，看为什么不对，这个可以看这个值是什么时候赋值的，为什么赋值不对，一步步逼近原因的真相。
5. 找出root cause，fix bug，然后一定再重新run一次，测试bug是否已经fix！
基本上，根据步骤1-5都能够解决90%的bug。但是世事无绝对，凡事都有例外，就像真假美猴王里的六耳猕猴，在无界之外。比如OOM内存泄露，闪退等问题，是不能用常规手段来发现问题的，只能通过统计学的方法，和经验来发现，比如MAT分析，sysTrace, timeTrace等专业分析工具。当然前提也是必须能够不断重现，然后
找出root cause，fix bug，测试！
如果还是不能解决的话，这个时候就要用到工作中的soft skill了：
1. 上网搜寻找类似问题，反编译模仿等。
2. 寻求其他人的帮助
3. 最后一步，举旗，不要把球抱在自己怀中
这样，通过不断的escalate，把问题充分暴露出来，而不至于一个bug让你停滞不前，耗费大量的时间。
当然以上方法和你自身的技术水平是相关的，水平高的能够快速定位，而水平一般的可能会用更多的时间。但是，总而言之，它能够让你固定的套路，以不变应万变，一步步逼近事情的真相！再多说一句，任何技术上的问题，都应该以量化的办法来解决，千万不要凭感觉，猜，靠经验等等。只有用数据说话，才是最科学的解决办法。因为，我发现有些5年以上工作经验的开发者，依然会靠一些经验来解决问题，但是问他怎么解决的时候拿不出数据，只能说凭感觉，经验，这些都是不专业的态度和精神。
希望对大家有用。