3

你有什么建议摆脱对生产软件的 pdb 调用?就我而言,我正在开发一个 django 网站。

我不知道我是否应该:

  • 来自 settings.py 的猴子补丁 pdb(取决于 DEBUG 布尔值)。
  • 为我们的项目制作一个 pdb 包装器,如果 DEBUG = True 则公开 set_trace 或打印基本日志
  • Dissalow 在 git hooks 上提交 brakpoints ......(如果你认为这是最好的主意,你会怎么做?)。
4

3 回答 3

2

第三个。您必须强制执行一些提交规则。例如,在提交之前运行一系列测试等。这样,开发人员就有了一种简单的方法来检查是否存在 pdb 中断。如果有人提交了 set_trace,他必须为团队的其他成员烤蛋糕。

这在我的公司工作得很好:-)

编辑:您可以将此方法作为 CDD(Cake Driven Developpement)介绍给您的老板

于 2011-08-11T14:53:39.497 回答
1

最好的选择是拥有一个广泛的测试套件,并在投入生产之前运行测试。无关pdb的断点会阻止测试通过。

如果你不能这样做,那么选项 2 是最好的:编写一个实用程序来闯入调试器,并使其对设置状态敏感。您仍然必须解决如何确保人们使用包装器而不是原始pdb调用的问题。

于 2011-08-11T14:48:41.600 回答
0

理想情况下,您不应该首先包含调试代码。您可以改为使用设置断点并调用主程序进行调试的包装器,以便主程序根本不包含实际set_trace()调用。

# foo.py
print "hello"
print "goodbye"

#debug_foo.py
import pdb

def run_foo():
    execfile('foo.py')

db = pdb.Pdb()
db.set_break("foo.py", 2)
db.run("run_foo()")

例子:

[~]$  python foo.py 
你好
再见
[~]$  python foo.py 
> <字符串>(1)<模块>()
(pdb)继续
你好
> /home/dbornside/foo.py(1)<模块>()
-> 打印“再见”
(pdb)继续
再见
[~]$ 
于 2011-08-11T15:25:38.667 回答