mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-22 23:00:57 +08:00
Update and rename sources/tech/20220830 Some ways to get better at debugging.md to translated/tech/20220830 Some ways to get better at debugging.md
This commit is contained in:
aftermath0703
GitHub
parent
244dec2682
commit
aa7b10bad1
@ -1,139 +0,0 @@
|
||||
[#]: subject: "Some ways to get better at debugging"
|
||||
[#]: via: "https://jvns.ca/blog/2022/08/30/a-way-to-categorize-debugging-skills/"
|
||||
[#]: author: "Julia Evans https://jvns.ca/"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: "aftermath0703"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
Some ways to get better at debugging
|
||||
======
|
||||
Hello! I’ve been working on writing a zine about debugging for a while (here’s [an early draft of the table of contents][1]).
|
||||
|
||||
As part of that I thought it might be fun to read some academic papers about
|
||||
debugging, and last week [Greg Wilson][2] sent me some
|
||||
papers about academic research into debugging.
|
||||
|
||||
One of those papers ([Towards a framework for teaching debugging
|
||||
[paywalled]][3]) had a
|
||||
categorization I really liked of the different kinds of knowledge/skills we
|
||||
need to debug effectively. It comes from another more general paper on
|
||||
troubleshooting: [Learning to Troubleshoot: A New Theory-Based Design Architecture][4].
|
||||
|
||||
I thought the categorization was a very useful structure for thinking about how
|
||||
to get better at debugging, so I’ve reframed the five categories in the paper
|
||||
into actions you can take to get better at debugging.
|
||||
|
||||
Here they are:
|
||||
|
||||
#### 1. learn the codebase
|
||||
|
||||
To debug some code, you need to understand the codebase you’re working with.
|
||||
This seems kind of obvious (of course you can’t debug code without
|
||||
understanding how it works!).
|
||||
|
||||
This kind of learning happens pretty naturally over time, and actually
|
||||
debugging is also one of the best ways to *learn* how a new codebase works –
|
||||
seeing how something breaks helps you learn a lot about how it works.
|
||||
|
||||
The paper calls this “System Knowledge”.
|
||||
|
||||
#### 2. learn the system
|
||||
|
||||
The paper mentions that you need to understand the programming language, but I
|
||||
think there’s more to it than that – to fix bugs, often you need to learn a
|
||||
lot about the broader environment than just the language.
|
||||
|
||||
For example, if you’re a backend web developer, some “system” knowledge you
|
||||
might need includes:
|
||||
|
||||
* how HTTP caching works
|
||||
* CORS
|
||||
* how database transactions work
|
||||
|
||||
I find that I often have to be a bit more intentional about learning systemic
|
||||
things like this – I need to actually take the time to look them up and read
|
||||
about them.
|
||||
|
||||
The paper calls this “Domain Knowledge”.
|
||||
|
||||
#### 3. learn your tools
|
||||
|
||||
There are lots of debugging tools out there, for example:
|
||||
|
||||
* debuggers (gdb etc)
|
||||
* browser developer tools
|
||||
* profilers
|
||||
* strace / ltrace
|
||||
* tcpdump / wireshark
|
||||
* core dumps
|
||||
* and even basic things like error messages (how do you read them properly)
|
||||
|
||||
I’ve written a lot about debugging tools on this blog, and definitely
|
||||
learning these tools has made a huge difference to me.
|
||||
|
||||
The paper calls this “Procedural Knowledge”.
|
||||
|
||||
#### 4. learn strategies
|
||||
|
||||
This is the fuzziest category, we all have a lot of strategies and heuristics
|
||||
we pick up along the way for how to debug efficiently. For example:
|
||||
|
||||
* writing a unit test
|
||||
* writing a tiny standalone program to reproduce the bug
|
||||
* finding a working version of the code and seeing what changed
|
||||
* printing out a million things
|
||||
* adding extra logging
|
||||
* taking a break
|
||||
* explaining the bug to a friend and then figuring out what’s wrong halfway through
|
||||
* looking through the github issues to see if anything matches
|
||||
|
||||
I’ve been thinking a lot about this category while writing the zine, but I want
|
||||
to keep this post short so I won’t say more about it here.
|
||||
|
||||
The paper calls this “Strategic Knowledge”.
|
||||
|
||||
#### 5. get experience
|
||||
|
||||
The last category is “experience”. The paper has a really funny comment about this:
|
||||
|
||||
> Their findings did not show a significant difference in the strategies
|
||||
employed by the novices and experts. Experts simply formed more correct
|
||||
hypotheses and were more efficient at finding the fault. The authors suspect
|
||||
that this result is due to the difference in the programming experience between
|
||||
novices and experts.
|
||||
|
||||
This really resonated with me – I’ve had SO MANY bugs that were really
|
||||
frustrating and difficult the first time I ran into them, and very straightforward
|
||||
the fifth or tenth or 20th time.
|
||||
|
||||
This also feels like one of the most straightforward categories of knowledge to
|
||||
acquire to me – all you need to do is investigate a million bugs, which is our
|
||||
whole life as programmers anyway :). It takes a long time but I feel like it
|
||||
happens pretty naturally.
|
||||
|
||||
The paper calls this “Experiential Knowledge”.
|
||||
|
||||
#### that’s all!
|
||||
|
||||
I’m going to keep this post short, I just really liked this categorization and
|
||||
wanted to share it.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://jvns.ca/blog/2022/08/30/a-way-to-categorize-debugging-skills/
|
||||
|
||||
作者：[Julia Evans][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://jvns.ca/
|
||||
[b]: https://github.com/lkxed
|
||||
[1]: https://twitter.com/b0rk/status/1562480240240525314?s=20&t=BwKd6i0mVCTaCud2HDEUBA
|
||||
[2]: https://third-bit.com/
|
||||
[3]: https://dl.acm.org/doi/abs/10.1145/3286960.3286970
|
||||
[4]: https://www.researchgate.net/profile/Woei-Hung/publication/225547853_Learning_to_Troubleshoot_A_New_Theory-Based_Design_Architecture/links/556f471c08aec226830a74e7/Learning-to-Troubleshoot-A-New-Theory-Based-Design-Architecture.pdf
|
||||
119
translated/tech/20220830 Some ways to get better at debugging.md
Normal file
119
translated/tech/20220830 Some ways to get better at debugging.md
Normal file
@ -0,0 +1,119 @@
|
||||
[#]: subject: "Some ways to get better at debugging"
|
||||
[#]: via: "https://jvns.ca/blog/2022/08/30/a-way-to-categorize-debugging-skills/"
|
||||
[#]: author: "Julia Evans https://jvns.ca/"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: "aftermath0703"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
提高调试能力的一些方法
|
||||
======
|
||||
你们好！我一直在编写一本关于调试的杂志（这是 [目录的初稿][1]).
|
||||
|
||||
作为其中的一部分，我认为阅读一些关于调试的学术论文可能会很有趣，上周[Greg Wilson][2]给我发了一些关于调试学术研究的论文。
|
||||
|
||||
其中一篇论文（[Towards a framework for teaching debugging
|
||||
[paywalled]][3]）对我们有效调试所需的不同种类的知识/技能进行了分类，我非常喜欢。
|
||||
它来自另一篇关于故障排除的更一般性的论文。[Learning to Troubleshoot: A New Theory-Based Design Architecture][4]。
|
||||
|
||||
我认为这个分类对于思考如何更好地进行调试是一个非常有用的结构，所以我把论文中的五个类别重新规划为你可以采取的行动，以提高调试的效率。
|
||||
|
||||
以下是这些行动：
|
||||
|
||||
#### 1. 学习代码库
|
||||
|
||||
要调试一些代码，你需要了解你正在使用的代码库。
|
||||
这似乎有点显而易见（当然，不了解代码的工作原理，你就无法调试代码！）
|
||||
|
||||
这种学习随着时间的推移会很自然地发生，
|
||||
而且实际上调试也是 *学习* 一个新的代码库如何工作的最好方法之一——
|
||||
看到一些代码是如何崩溃的，有助于你了解它是如何工作的。
|
||||
|
||||
本文将此称为 "系统知识"。
|
||||
|
||||
#### 2. 学习系统
|
||||
|
||||
论文中提到，你需要了解编程语言，但我认为不止于此——为了修复bug，往往你需要学习很多更广泛的环境，而不仅仅是语言。
|
||||
|
||||
举个例子，如果你是后端web开发者，你可能需要的一些“系统”知识包括：
|
||||
|
||||
* HTTP缓存如何工作
|
||||
* CORS
|
||||
* 数据库事务是如何工作的
|
||||
|
||||
我发现我经常需要更有意识地去学习像这样的系统性的东西——我需要真正花时间去查找和阅读它们。
|
||||
|
||||
本文将此称为 "领域知识"。
|
||||
|
||||
#### 3. 学习你的工具
|
||||
|
||||
现在有很多工具，例如：
|
||||
|
||||
* 调试器（GDB等）
|
||||
* 浏览器开发工具
|
||||
* 剖析器（profilers）
|
||||
* strace / ltrace
|
||||
* tcpdump / wireshark
|
||||
* 核心转储
|
||||
* 甚至像错误信息这样的基本东西（如何正确阅读它们）
|
||||
|
||||
我在这个博客上写了很多关于调试工具的文章，并且肯定学习这些工具给我带来了巨大的变化。
|
||||
|
||||
本文将此称为 "处理性知识"。
|
||||
|
||||
#### 4. 学习策略
|
||||
|
||||
这是最模糊的一类，在如何高效调试的过程中，我们都有很多策略和启发式方法。比如说：
|
||||
|
||||
* 写一个单元测试
|
||||
* 写一个小的独立程序来重现这个错误
|
||||
* 找到一个能工作的版本的代码，看看有什么变化
|
||||
* 打印出无数的东西
|
||||
* 增加额外的日志记录
|
||||
* 休息一下
|
||||
* 向朋友解释这个错误，然后在中途发现问题所在
|
||||
* 查看github上的问题，看看是否有匹配的问题
|
||||
|
||||
在写这本杂志的时候，我一直在思考这个类别，但我想让这篇文章简短，所以我不会在这里多说。
|
||||
|
||||
本文将此称为 "战略知识"。
|
||||
|
||||
#### 5. 获得经验
|
||||
|
||||
最后一个类别是 "经验"。这篇论文对此有一个非常有趣的评论：
|
||||
|
||||
|
||||
> 他们的研究结果并没有显示出新手和专家所采用的策略有什么明显的区别。
|
||||
专家只是形成了更多正确的假设，并且在寻找故障方面更有效率。
|
||||
作者怀疑这个结果是由于新手和专家之间的编程经验不同造成的。
|
||||
|
||||
这真的引起了我的共鸣——我遇到过很多第一次遇到时非常令人沮丧和困难的bug，而在第五次、第十次或第二十次时就非常简单了。
|
||||
|
||||
对我来说，这也是最直接的知识类别之一——
|
||||
你需要做的就是调查一百万个bug，反正这就是我们作为程序员的全部生活 :) 。
|
||||
这需要很长的时间，但我觉得它发生得很自然。
|
||||
|
||||
本文将此称为 "经验知识"。
|
||||
|
||||
#### 就这样吧!
|
||||
|
||||
我打算把这篇文章写得很短，我只是非常喜欢这个分类，想把它分享出来。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://jvns.ca/blog/2022/08/30/a-way-to-categorize-debugging-skills/
|
||||
|
||||
作者：[Julia Evans][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[aftermath0703](https://github.com/aftermath0703)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://jvns.ca/
|
||||
[b]: https://github.com/lkxed
|
||||
[1]: https://twitter.com/b0rk/status/1562480240240525314?s=20&t=BwKd6i0mVCTaCud2HDEUBA
|
||||
[2]: https://third-bit.com/
|
||||
[3]: https://dl.acm.org/doi/abs/10.1145/3286960.3286970
|
||||
[4]: https://www.researchgate.net/profile/Woei-Hung/publication/225547853_Learning_to_Troubleshoot_A_New_Theory-Based_Design_Architecture/links/556f471c08aec226830a74e7/Learning-to-Troubleshoot-A-New-Theory-Based-Design-Architecture.pdf
|
||||
Loading…
Reference in New Issue
Block a user