* [Chinese-Traditional](zh-traditional/)

[//]: # (Version:1.0.0)

除錯是成為程式設計師的基石。除錯這個詞第一個含義是移除錯誤,但真正有意義的含義是透過檢查來觀察程式的運行。一個不會除錯的程式設計師等同於盲人。

理想主義者認為設計、分析、複雜的理論或其他東西比實際除錯更基本,他們不是現實的程式設計師。現實的程式設計師不會活在理想的世界裡。即使你是完美的,你也需要與你周圍主要的軟體公司或組織的程式碼,和你同事寫的程式碼打交道。這些程式碼和它們的文件大多數都是不完美的。如果不能洞察程式碼的具體執行過程,最小的変動都會把你永遠地拋出去。通常這種可見性只能從實驗獲得,也就是除錯。

除錯是與程式運行相關的事情,而非與程式本身相關。你從主要的軟體公司購買一些產品,通常不會看到產品背後的程式碼。但程式碼不遵循文件的情況或文件沒有說明的情況仍然會出現。更常見的是,你的程式出現了一個錯誤,當你檢查你寫的程式碼的時候,卻不知道這個錯誤是怎麼發生的。這意味著你做的一些假設並不對,或者一些你沒有預料到的情況發生了。有時候,奇妙的修改程式碼的技巧可能會生效。當無效時,你必須除錯。

為了獲得程式執行過程的可見性,你必須能夠執行程式碼並從這個過程中觀察到發生了什麼。有時候這是顯而易見的,比如一些正在呈現在螢幕上的東西,或者兩個事件之間的延遲。在許多其他的案例中,除錯與一些不一定可見的東西相關,比如程式碼中一些變量的狀態,哪一行程式碼正在被執行,或者一些斷言是否持有了一個複雜的資料結構。這些隱藏的細節必須被顯露出來。

觀察一個正在執行程式的內部的方法通常可按如下分類:

- 使用一個除錯工具;

- Logging [(詳情看)](../../4-Glossary.md) - 利用打印程式句子顯示變數值，找出流程出錯地方。

當除錯工具穩定可用時,它們是非常美妙的,但 Printlining 和寫日志甚至是更加重要的。除錯工具通常落後於編程語言的發展,所以在某些時候它們都可能是無效的。另外,除錯工具可能輕微改變程式實際執行的方式。最后,除錯有許多種,比如檢查一個斷言和一個巨大的資料結構,這需要寫程式碼並改變程式的運行。當除錯工具可用時,知道如何使用除錯工具是一件好事,但學會使用其他兩種方式也是至關重要的。

當除錯需要修改程式碼的時候,一些初學者會感到害怕。這是可以理解的,這有點像探索性外科手術。但你需要學會打破程式碼,讓它跳起來,你需要學會在它上面做實驗,並需要知道你臨時對它做的任何事情都不會使它變得更糟。如果你感受到了這份恐懼,找一位導師 - 正是因為許多人在一開始面對這種恐懼的時候表現的太脆弱,我們因此失去了很多本可以變成優秀程式設計師的人。

Next [如何通过分离问题空间来 Debug](02-How-to-Debug-by-Splitting-the-Problem-Space.md)

[//]: # (Version:1.0.0)

调试是有趣的，因为它一开始是个迷。你认为它应该这样做，但实际上它却那样做。很多时候并不仅是这么简单---我给出的任何例子都会被设计来与一些偶尔在现实中会发生的情况相比较。调试需要创造力与智谋。如果说调试有简单之道，那就是在这个谜题上使用分治法。

假如，你创建了一个程序，它会依次执行十件事情。当你运行它的时候，它却崩溃了。但你本来的目的并不是想让它崩溃，所以现在一个谜题扔给你了。当你查看输出时，你可以看到序列里前七件事情运行成功了。最后三件事情在输出里却看不到，所以你的谜题变小了：“它是在执行第8、9、10件事的时候崩溃的”。

你是否可以设计一个实验来观察它是在哪件事情上崩溃呢？当然，你可以用一个调试器或者我们可以在第8第9件事后面加一些[printlining](../../4-Glossary.md)的语句（或者你正在使用的任何语言里的等价的事情），当我们重新运行它的时候，我们的谜题会变得更小，比如“它是在做第九件事的时候崩溃的”。我发现，把谜题是怎样的一直清楚地记在心里能让我们保持注意力。当几个人在一个问题的压力下一起工作时，很容易忘记最重要的谜题是什么。

调试技术中分治的关键和算法设计里的分治是一样的。你只要从中间开始划分，就不用划分太多次，并且能快速地调试。但问题的中点在哪里？这就是真正需要创造力和经验的地方了。

对于一个真正的初学者来说，可能发生错误的地方好像在代码的每一行里都有。一开始，你看不到一些你稍后开发的时候才会看到的其它纬度，比如执行过的代码段，数据结构，内存管理，与外部代码的交互，一些有风险的代码，一些简单的代码。对于一个有经验的程序员，这些其他的维度为整个可能出错的事情展示了一个不完美但是有用的思维模型。拥有这样的思维模型能让一个人更高效地找到谜题的中点。

一旦你最终划分出了所有可能出错的地方，你必须试着判断错误躲在哪个地方。比如：这样一个谜题，哪一行未知的代码让我的程序崩溃了？你可以这样问自己，出错的代码是在我刚才执行的程序中间的那行代码的前面还是后面？通常你不会那么幸运就能知道错误在哪行代码甚至是哪个代码块。通常谜题更像这个样子的：“图中的一个指针指向了错误的结点还是我的算法里变量自增的代码没有生效？”，在这种情况下你需要写一个小程序去确认图中的指针是否都是对的，来决定分治后的哪个部分可以被排除。

Next [如何移除错误](03-How-to-Remove-an-Error.md)

[//]: # (Version:1.0.0)

我曾有意把检查程序执行和修复错误分割开来，但是当然，调试也意味着移除 bug。理想状况下，当你完美的发现了错误以及它的修复方法时，你会对代码有完美的理解，并且有一种顿悟(啊哈！)的感觉。但由于你的程序会经常使用其他不具有可视性的、没有一致性注释的系统（比如第三方库），所以完美是不可能的。在其他情况下，可能代码是如此的复杂以至于你的理解可能并不完美。

在修复 bug 时，你可能想要做最小的改变来修复它。你可能看到一些其他需要改进的东西，但不会同时去改进他们。请使用科学的方法去改进一个东西，并且一次只改变一个东西。修复 bug 最好的方式是能够重现 bug，然后把你的修复替换进去，重新运行你的程序，观察，直到 bug 不再出现。当然，有时候不止一行代码需要修改，但你在逻辑上仍然需要使用一个独立原子(译者注：以前人们认为原子不可再分，所以用用原子来代表不可再分的东西)的改变来修复这个 bug。

有时候，可能实际上有几个 bug，但表现出来好像是一个。这取决于你怎么定义 bug，你需要一个一个地修复它们。有时候，程序应该做什么或者原始作者想要做什么是不清晰的。在这种情况下，你必须多加练习，增加经验，评判并为代码赋予你自己的认知。决定它应该做什么,并注释或用其他方式阐述清楚，然后修改代码以遵循你赋予的含义。这是一个进阶或高级的技能，有时甚至比一开始用原始的方式创建这些代码还难，但真实的世界经常是混乱的。你必须修复一个你不能重写的系统。

Next [如何使用日志调试](04-How-to-Debug-Using-a-Log.md)

[//]: # (Version:1.0.0)

*Logging*（日志）是一种编写系统的方式，可以产生一系列信息记录，被称为 log。*Printlining* 只是输出简单的，通常是临时的日志。初学者一定要理解并且使用日志，因为他们对编程的理解是局限的。因为系统的复杂性,系统架构必须理解与使用日志。在理想的状态下，程序运行时产生的日志信息数量需要是可配置的。通常，日志提供了下面三个基本的优点：

- 日志可以提供一些难以重现的 bug 的有效信息，比如在产品环境中发生的、不能在测试环境重现的 bug。

- 日志可以提供统计和与性能相关的数据，比如语句间流逝过的时间。

- 可配置的情况下，日志允许我们获取普通的信息，使得我们可以在不修改或重新部署代码的情况下调试以处理具体的问题。

需要输出的日志数量总是一个简约与信息量的权衡。太多的信息会使得日志变得昂贵，并且造成[*滚动目盲*](../../4-Glossary.md)，使得发现你想要的信息变得很困难。但信息太少的话，日志可能不包含你需要的信息。出于这个原因，让日志的输出可配置是非常有用的。通常，日志中的每个记录会标记它在源代码里的位置，执行它的线程（如果可用的话），时间精度，并且通常还有一些额外的有效信息，比如一些变量的值，剩余内存大小，数据对象的数量，等等。这些日志语句撒遍源码，但只出现在主要的功能点和一些可能出现危机的代码里。每个语句可以被赋予一个等级，并且只有在系统被配置成输出相应等级的记录的时候才输出这个等级的记录。你应该设计好日志语句来标记你预期的问题。预估测量程序表现的必要性。

如果你有一个永久的日志，printling 现在可以用日志的形式来完成，并且一些调试语句可能会永久地加入日志系统。

Next [如何理解性能问题](05-How-to-Understand-Performance-Problems.md)