崔雨锴
这个问题对专业的来说是常识，不过我还是简单解释一下给外行看吧。权当娱乐。
找Bug这事，最简单就是用开发工具，在代码执行的时候设置断点，看每条代码执行之后的结果是否符合预期。程序员也会在一些地方把软件的状态记录在日志文件里，就像飞机的黑盒子那样的，当程序出现问题的时候反查日志，也会对找到问题有帮助。
这些都是小儿科，但程序员几乎每天都在做这些。
对于像Facebook这种大型软件公司，如果光指望程序员这样干，那就不要玩了，有一套系统性的方法，叫做软件工程，专门研究的是如何科学地管理软件开发的过程。还有一系列质量认证来评估组织的过程管理能力，比如SEI-CMMI，类似工厂常用的ISO 9000系列，很多政府组织都要求有相关的资质才能接他们的项目。这里就不展开了。
对创业公司而言，完全实施这种严谨的软件过程成本很高。没有50人以上，组织角色都凑不齐，不太现实。但是一般而言，每日构建还是最基本的开发实践。
首先，所有代码要有相关的测试代码。比如，一个计算加法的程序，要有另一套程序负责测试其结果是否正确，用多种设计好的边界数据进行检验。当然做加法的代码不值得这样，仅为举例，不过大公司的测试程序数量远远大于正常的功能代码，也要经过严格的同行评审才能提交入库。
其次，比如微软是每天五点之前每个人上传当天改过的程序，系统编译过后自动执行所有测试程序，保证所有人改过的集成之后，各种功能可以正常工作。这个测试会包含功能、性能及各种极端用例，通常会持续数个小时。软件人员最怕就是下班了接到自己的代码测试出错的信息，那就意味着当天要改完通过测试，不然代码库会回滚到一天前，当日所有人的工作无进展。
尽管如此，总有一些问题会在上线后发生。毕竟各种硬件设备和运行环境的组合是个天文数字，手工找Bug还是免不了。这时候就看经验了，高手的效率也许是生手的上百倍。所以很多软件公司的高管都是技术出身，否则做个睁眼瞎，不知道会多花多少冤枉钱。
冬河草
我在通信研发干过，做的是核心网设备操作系统中某个模块的开发，整个公司的通信设备软件代码量加起来惊人，不亚于任何大型的软件公司，那么我们怎么能快速定位到缺陷呢？
首先软件代码不可能一大坨，而是遵从自上而下的划分原则有效的模块化的。以前东家为例，那时候我们首先分设备（基站、接入网还是核心网），在设备上又分大的功能域Domain，在每个领域下又分若干个软件模块（我们称为programblock或简称PRB）。每个软件模块可以看做是可以独立运行的程序，与其它模块通过协议接口交互。于是每个开发团队会负责若干个软件模块的开发测试及维护。我们的代码库里可以看到上千个软件模块，各自还有若干的版本和分支，其复杂度可想而知。
为便于维护和缺陷定位，我们都有严格的日志规范与标准，在不同的异常情况下要写不同等级的日志，如警告、严重及致命等。这样前方技术支持在发生问题的时候可以通过抓取日志来分析哪些软件模块报了什么样的问题，尤其关注那些等级高的日志。后端的研发人员通过查看日志及相关参数记录，就能快速定位到某个具体模块的代码位置。
另外，开发团队还要承担本地的测试工作，一直管到功能测试为止，即单元测试、功能测试还有回归测试。在这之上，团队的测试专家还要配合系统测试团队写集成测试以及性能测试用例。这有利于团队熟悉自己代码所对应的应用场景，并且通过回归测试来保证新的开发不破坏老的功能。
最后就是有效的代码库管理。我们那时候用的是SVN，但代码合并不是随意的，有专人负责，有测试用例保护，还需要经过代码审查。未审查过的代码严禁提交合并，测试用例没跑过的也不许提交。本地提交改动前还要遵循规范操作，比如必须先将代码拉取到本地，有冲突的本地解决才能提交，以避免代码冲突和缺失等。
综上所述，对产品进行模块化分工、严格的代码管理、充分的测试还有有效的日志工具，都是工程师能快速定位大型软件代码缺陷的有效手段。
江南渔夫
在脸书如何找bug没有开发新功能重要。绝大部分工程师工作的目标都是为了performance好看。修bug并不会对performance有多大作用，除非是修别人造成的sev级别bug。所以很多时候就算发现了bug也不会管，而是专心完成手头项目。
Ca2019
单元测试，模拟测试，跟踪流程就这么找bug，就目前我是这么做的！
说的不多_多的不说
题主您好。
在开发的时候，无论是什么语言，我们都会使用一个工具，叫做 “日志”，我们会在自己的代码中加入各种各样的日志，从而辅助判断检测问题的所在之处。
此外，我们还可以借助一些Debug工具，来辅助进行错误的定位。
