文章内容为摘抄，并非原创，自己记录只是日后方便翻阅。
一、那么我们如何才能更快地定位出bug产生的位置呢？下面我提供一些思路供大家参考
1.断点调试法。
这是程序员通用，同时也是最有效的定位问题的方式。一个不会断点调试的程序员和瞎子没有本质上的区别。
2.日志分析法。
其实并不是所有bug都可以进行断点调试的。比如在一些循环调用或者业务较为复杂的场景下，打日志分析定位是较为适合的方式。
3.排除法。
如果一个bug产生的原因可能有多种情况的时候，这个时候采取排除法的方式是最优的。你可以把可能导致bug产生的代码块都打上日志或者断点，然后重现一下bug进行问题的定位。
4.代码回滚法。
如果你这个bug在之前的版本是好的，但是在现在版本上又出现了，这个时候就可以使用代码回滚大法。把你的代码回滚到你怀疑的版本，运行看bug是否消失，然后对两个版本之前代码有何区别，最终定位出bug产生的位置。这里我们可以使用二分法来提高代码的回滚效率。
5.注释（删除）代码法。
这个我在上一个步骤中也提到过。对于一些难以理解和定位的bug，我们可以使用这个方法进行尝试。不过这个方法使用起来有一定的风险，因为可能你删除的那一串代码虽然能够解决bug，但是却不是bug产生的根源，这个时候你可能会将必现bug改成了偶现bug，让问题变得更加复杂。
6.源码分析法。
有的时候有些bug可能并不是你的代码导致的问题。可能是第三方库本身的bug，又或者是系统本身的bug，又或者是你误用api导致的问题，这个时候就需要你拥有源码分析的能力。深入源码中，一层层分析直到最终找到bug产生的原因。
7.联想法。
通过一些类似的bug修改经验从而联想猜测出bug产生的位置。这个方法对使用者本身有较高的要求。需要使用者对项目代码和业务逻辑非常熟悉，同时对问题分析的能力有较高的要求。这就是我们常说的牛人能够一眼就能看出问题，他们常用的就是这种方式。
8.场外支援法。
这是实在定位不出bug才采取的下下策。因为它并不能提高你定位bug的能力，同时请别人帮忙定位bug，你就需要把你之前所做的工作都要全盘地向他表述一遍，这样不仅会降低bug修复的效率，同时还不一定能保证定位出bug产生的位置，它取决于你表述问题的能力和帮你的人分析和解决问题的能力。
二、工作9年，我把我的职场认知列成清单，和你一起分享
1、领导分配任务时，要及时问清楚
- 可以先说自己的理解，向上司求证这样理解是否无误，
- 然后才开始执行任务。
- 如果不在一开始就确认清楚，后面才问这问那是在占用上司的时间，会被上司贴上不好的标签。
不清楚的地方不要猜，一定要问清楚。
特别是职场新人刚进公司，学校的沟通方式和企业的沟通方式，完全不在一个频道上。这恰恰是新人应该注意的地方：
要想完成任务，我们就得知道：
- 我们认为的“任务”，是否和领导要求的“任务”一致？
- 我们认为的“完成”，是否和领导定义的“完成”一致？
- 我们认为的“优秀”，是否和领导眼里的“优秀”一致？
这些沟通的问题，很可能导致你信心满满的提交任务，而你的上司却等得着急，看得崩溃，气得上火，差点就拍桌子了。
2、工作上保持跟进（follow up）
职场上，我们也常常听到类似这样的话。工作做了，过程也很辛苦，但是没有达到有效的结果，理由还很充分，我已经尽力了，至于工作没有做好，请别怪我！
为什么有的人看起来很勤奋地工作，暗地里累死累活，加班加点，到头来客户和领导都不满意，甚至还被人说这人不靠谱。之所以出现这种情况，大多数情况下是我们忽略了跟进，没有及时反馈进度。有时候工作效率低并不是能力不强，而是日常工作的一些小细节降低了工作效率。在大问题上，我们往往会足够的重视，所以很少会出现原则性错误；而一些小细节，却容易在思想上被我们所忽视。
就像挖井，有人会说“挖坑了，没有水，别怪我”，看起来像是完成了任务（挖水），过程也很辛苦（挖了不少的坑），但是却没有得到有效的结果（挖到水），理由还很充分（挖坑了！没有水！别怪我！）。
领导交代工作时，其实真正想要的并非是任务和事情本身，而是让我们拿到有价值的结果，不是“挖水”，而是“挖到水”。
跟进，简单来说就是你负责的事情要负责到底。
3、积极帮助同事解决问题
在不影响别人工作进度，不给别人添麻烦，自己力所能及范围内，帮同事解决问题。
4、做总结和思考
新人难免因为对公司系统、产品不熟要向前辈请教。虚心求教是好事儿，事实上，不少老员工很愿意帮助新人成长。但别人教你的东西，请带上本子和笔，不能记住的要记笔记，这个很重要。切记下次不要再问类似的问题。这是对别人时间和成果的一种尊重。别人的帮助帮你解决了问题，别忘记反馈致谢，你记得别人的好，别人也更乐意帮你
学会自我反馈与复盘。进步的最佳方式，是工作完成后马上跟进你的反思与复盘。也不要有路径依赖。哪怕你每天都在重复同一个任务，也要勤于思考这件事情有没有更优解。
