mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-29 21:41:00 +08:00
70 lines
3.3 KiB
Markdown
70 lines
3.3 KiB
Markdown
Python 调试技巧
|
|
======
|
|
|
|
当进行调试时，你有很多选择，但是很难给出一直有效的通用建议（除了“你试过关闭再打开么？”以外）。
|
|
|
|
这里有一些我最喜欢的 Python 调试技巧。
|
|
|
|
### 建立一个分支
|
|
|
|
请相信我。即使你从来没有打算将修改提交回上游，你也会很乐意将你的实验被包含在它们自己的分支中。
|
|
|
|
不说别的，它会使清理更容易！
|
|
|
|
### 安装 pdb++
|
|
|
|
认真地说，如果你使用命令行，它会让你的生活更轻松。
|
|
|
|
pdb++ 所做的一切就是用更好的模块替换标准的 pdb 模块。以下是你在 `pip install pdbpp` 会看到的：
|
|
|
|
* 彩色提示！
|
|
* 制表符补全！（非常适合探索！）
|
|
* 支持切分！
|
|
|
|
好的，也许最后一个是有点多余……但是非常认真地说，安装 pdb++ 非常值得。
|
|
|
|
### 探索
|
|
|
|
有时候最好的办法就是胡乱试试，然后看看会发生什么。在“明显”的位置放置一个断点并确保它被命中。在代码中加入 `print()` 和/或 `logging.debug()` 语句，并查看代码执行的位置。
|
|
|
|
检查传递给你的函数的参数，检查库的版本（如果你已经非常绝望了）。
|
|
|
|
### 一次只能改变一件事
|
|
|
|
在你在探索了一下后，你将会对你可以做的事情有所了解。但在你开始摆弄代码之前，先退一步，考虑一下你可以改变什么，然后只改变一件事。
|
|
|
|
做出改变后，然后测试一下，看看你是否接近解决问题。如果没有，请将它改回来，然后尝试其他方法。
|
|
|
|
只更改一件事就可以让你知道什可以工作，哪些不工作。另外，一旦可以工作后，你的新提交将会小得多（因为将有更少的变化）。
|
|
|
|
这几乎是<ruby>科学过程<rt>Scientific Process</rt></ruby>中所做的事情：一次只更改一个变量。通过让自己看到并衡量一次更改的结果，你可以节省你的理智，并更快地找到解决方案。
|
|
|
|
### 不要假设，提出问题
|
|
|
|
偶尔一个开发人员（当然不是你咯！）会匆忙提交一些有问题的代码。当你去调试这段代码时，你需要停下来，并确保你明白它想要完成什么。
|
|
|
|
不要做任何假设。仅仅因为代码在 `model.py` 文件中并不意味着它不会尝试渲染一些 HTML。
|
|
|
|
同样，在做任何破坏性的事情之前，仔细检查你的所有外部关联。要删除一些配置数据？**请确保你没有连接到你的生产系统。**
|
|
|
|
### 聪明，但不要聪明过头
|
|
|
|
有时候我们编写的代码神奇般地奏效，不知道它是如何做的。
|
|
|
|
当我们发布代码时，我们可能会觉得自己很聪明，但当代码崩溃时，我们往往会感到愚蠢，我们必须记住它是如何工作的，以便弄清楚它为什么不起作用。
|
|
|
|
留意任何看起来过于复杂、冗长或极短的代码段。这些可能是隐藏复杂并导致错误的地方。
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
via: https://pythondebugging.com/articles/python-debugging-tips
|
|
|
|
作者：[PythonDebugging.com][a]
|
|
选题：[lujun9972](https://github.com/lujun9972)
|
|
译者：[geekpi](https://github.com/geekpi)
|
|
校对：[wxy](https://github.com/wxy)
|
|
|
|
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
|
|
|
[a]:https://pythondebugging.com
|