So, I started learning to code in Python and later Django. The first times it was hard looking at tracebacks and actually figure out what I did wrong and where the syntax error was. Some time has passed now and some way along the way, I guess I got a routine in debugging my Django code. As this was done early in my coding experience, I sat down and wondered if how I was doing this was ineffective and could be done faster. I usually manage to find and correct the bugs in my code, but I wonder if I should be doing it faster?
我通常只使用Django启用时提供的调试信息。当事情确实像我想象的那样结束时，我用一个语法错误破坏了代码流，并查看流中那个点的变量，以找出代码在哪里做了与我想要的不同的事情。
但这种情况还能改善吗?是否有一些更好的工具或方法来调试Django代码?
正如在其他文章中提到的，在你的代码中设置断点，然后遍历代码，看看它是否像你预期的那样运行，这是学习像Django这样的东西的好方法，直到你对它的所有行为以及你的代码在做什么有很好的感觉。
要做到这一点，我建议使用WingIde。就像其他提到的ide一样，很好很容易使用，布局很好，也很容易设置断点，计算/修改堆栈等。完美的可视化你的代码正在做什么，因为你逐步通过它。我是它的超级粉丝。
我还使用PyCharm——它有出色的静态代码分析，有时可以帮助你在意识到问题之前发现问题。
如前所述，django-debug-toolbar是必不可少的- https://github.com/django-debug-toolbar/django-debug-toolbar
虽然不是一个明确的调试或分析工具，但我最喜欢的一个是SQL打印中间件，可以从Django Snippets (https://djangosnippets.org/snippets/290/)上获得
这将显示视图生成的SQL查询。这将使您很好地了解ORM正在做什么，以及您的查询是否有效，或者您是否需要重做代码(或添加缓存)。
我发现它对于在开发和调试应用程序时监视查询性能非常有用。
还有一个技巧——我为自己的使用对它进行了稍微修改，只显示摘要而不显示SQL语句....所以我总是在开发和测试时使用它。我还补充说，如果len(connection.queries)大于预定义的阈值，它会显示一个额外的警告。
然后，如果我发现发生了一些不好的事情(从性能或查询数量的角度来看)，我会返回SQL语句的完整显示，以查看到底发生了什么。当你与多个开发人员一起开发一个大型Django项目时，这非常方便。
我刚找到wdb (http://www.rkblog.rk.edu.pl/w/p/debugging-python-code-browser-wdb-debugger/?goback=%2Egde_25827_member_255996401)。它有一个非常漂亮的用户界面/ GUI，所有的铃铛和口哨。作者这样说wdb -
“像PyCharm这样的ide有自己的调试器。它们提供了相似或相同的功能……然而，要使用它们，你必须使用那些特定的ide(其中一些是非免费的，或者可能不适用于所有平台)。根据你的需要选择合适的工具。”
我想我应该把它传下去。
这也是一篇关于python调试器的非常有用的文章:
https://zapier.com/engineering/debugging-python-boss/
最后，如果你想在Django中看到一个漂亮的调用堆栈的图形打印输出，checkout:
https://github.com/joerick/pyinstrument。只需将pyinstrument.middleware.ProfilerMiddleware添加到MIDDLEWARE_CLASSES中，然后将?profile添加到请求URL的末尾以激活剖析器。
也可以从命令行或导入作为模块运行pyinstrument。
