这发生在我们最好的人身上。
特别是在处理没有内置调试功能(如断点和监视变量)的语言时,这些错误会让开发人员感到困惑。调试代码,警报和Response.Writes,显示在生产代码中。
如何将调试问题与javascript,php或vbscript中的功能代码分开?您如何确保这些调试更改永远不会进入生产环境?
答案 0 :(得分:13)
最简单的方法
define("DEBUG", true);
if (DEBUG) {
echo "Debug Method";
}
对于js来说,它是相似的。
答案 1 :(得分:3)
人为错误难以预防
https://meta.stackexchange.com/questions/71780/lol-debugging-are-we-so-homepage-alerts-false
答案 2 :(得分:2)
一种方法是使用环境变量。在您的服务器配置中,您可以设置环境变量来表示调试与否。生产服务器将配置为false,并将开发设置为true。这样你在代码中所做的就是检查环境变量:
在PHP中:
if (getenv('DEBUG_MODE')) {
var_dump($foo);
}
这样,就没有办法忘记,因为它会自动关闭。但如果您真的需要在生产中打开它,只需翻转开关......
答案 3 :(得分:2)
有几种方法可以在生产中隐藏调试代码,但很少有方法可以删除它(当编译器无法自动删除它时)。
我通过以下方式隐藏调试代码:
我通过在部署前搜索特殊注释来删除它:
alert("false") //TODO:REMOVE DEBUG CODE
我的同事也建议:
alert
以检查调试变量。 (副作用?)alertDebug
方法以检查调试变量。 (有人会记得吗?)检查firebug是否正在运行
if(window.console && window.console.firebug)
{
alert("you are using firebug");
}
答案 4 :(得分:2)
它可能不完美但我的编辑器中有一个宏允许我添加调试并将其包装在适当的标记注释中。我还有一个脚本,我后来运行,将这些东西撕掉了。当然,我花了一段时间才真正相信这种机制,但随着时间的推移,我已经习惯了。
我的偏好是避免检查调试代码。显然,与任何其他“规则”一样,也存在例外情况,但由于以后很容易错过,我不喜欢检查它。
答案 5 :(得分:1)
如果您使用指定用于调试目的的语言功能,则往往会减少:
assert( is_string($param1) );
不会损害生产代码。
答案 6 :(得分:1)
由于最常见的答案存在安全漏洞,请允许我在php.net中加入风险较低的版本。
define ('DEBUG', 1);
if (DEBUG == 1) {
// echo some sensitive data.
}
基础知识是相同的,但如果常量DEBUG
未声明,则此代码不会执行调试代码。
if (DEBUG)
的问题是如果没有定义常量,它将假定字符串“DEBUG”,其值为true。
答案 7 :(得分:1)
如果仅“避免在生产环境中进行调试”,则使用内置的assert()函数。
这完全避免了调试消息的处理,并避免了其中可能进行的任何计算消耗内存或处理能力。
断言在生产中被完全忽略。
function debug(...$stuff){
var_dump($stuff);
return true; //always return true so assert will always pass it.
}
assert(debug("This code will not even be processed on production server. "));
这是最安全的方法,但不够灵活。
我经常使用的一种方法是检查主机名或客户端IP地址。
所以我有一个检查主机名的功能,如下所示:
function onTestServer(){
$SERVER_NAME = $_SERVER["SERVER_NAME"];
if(substr($SERVER_NAME,-5)==="te.st") return true;//all *.te.st domains are test servers
if (strpos($SERVER_NAME, ".localhost")!==false) return true; //all *.localhost domains are test servers
return false;
}
然后我有自己的vardump,debug和die语句,这些语句不会在生产环境中执行,类似于:
function varDump($stuff){
if (!onTestServer()) return;
echo "<pre>";
var_dump($stuff);
echo "</pre>";
}
然后,您只会使用自定义的varDump()函数,因此只有您可以看到它。
我的调试功能要复杂得多,并显示可扩展的信息树等。但是基本原理是相同的。如果在localhost上执行vardumps等,否则不显示任何内容。
如果您始终希望在测试时看到更多信息,但又不想在部署到服务器之前必须删除所有电子书,则非常方便。
如果客户端的IP地址是我自己的,我还会做一些事情,例如检查客户端的IP地址,并在实际的生产服务器上显示错误和信息。
function getIp()
{
if (!empty($_SERVER['HTTP_CLIENT_IP'])) //check ip from share internet
{
$ip=$_SERVER['HTTP_CLIENT_IP'];
}
elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) //to check ip is pass from proxy
{
$ip=$_SERVER['HTTP_X_FORWARDED_FOR'];
}
else
{
$ip=$_SERVER['REMOTE_ADDR'];
}
return $ip;
}
function onTestClient(){
$office_ip = "xxxx.xxxx.xxxx.xxxx";
$test_client_ips = array($office_ip,"any other ip you want");
$client_ip = getIp();
if (in_array($client_ip,$test_client_ips)) return true;
return false;
}
如果您需要在不使用本地测试环境的情况下从一台便携式计算机上在实时站点上测试一些快速更新,可以非常方便。只需将您当前的IP添加到列表中,并使用如下所示的功能即可:
function die_dev($message){
if (onTestServer() || onTestClient()) die($message);
}
甚至:
if (onTestClient()){
//show a completely different interface/webpage html js etc
} else {
//show the original content that is currently live
}
答案 8 :(得分:0)
代码评论。通常,当有人查看代码时,这种事情确实很突出。
答案 9 :(得分:0)
在代码进入生产之前,我们有多个测试阶段。每个阶段的不同测试人员组具有不同的目标。到目前为止似乎工作(我们从来没有像这样的调试代码进入生产)。
我打算说“代码评论”,但其他人已经说过了,而且我不确定它会不会有这样的东西......
答案 10 :(得分:0)
我所做的是在php
define ("DEBUG", true);
function op (){
if ( !DEBUG ) return true;
$args = func_get_args();
foreach ( $args as $var ){
if ( is_object ( $var ) or is_array ( $var ) ){
print "<br /><pre>";
print_r ( $var );
print "</pre>";
}
else{
print "<br />" . $var;
}
}
return true;
}
// On places to check
op ($array, $var);
在js中我也会像
一样function calert(message){
if (!debug) return;
alert (message);
}
答案 11 :(得分:0)
您是否直接在生产服务器上工作? 你听说过登台服务器或测试服务器吗? 您可以使用自己的计算机成为您的舞台服务器 - 使用Microsoft网络矩阵! 让您的代码清洁并在那里完美运行,然后转向生产。
没有其他好的方法可以确保在生产服务器上弹出调试代码 - 生产前的QA
答案 12 :(得分:0)
我遵循调试代码的三条规则
通过...
使源代码看起来很糟糕 not indenting it from the left margin
egregiously violating the coding standard
putting in extra whitespace above and below
设置全局调试开关,
have it alter an obvious output if it is ON, and
make the debug code compilation depend on that switch being ON (i.e., so the code won't compile if the global switch is OFF)
破坏明显的输出,例如:
delete something really important
put up 99/99/99, for the date
comment out the "File Load" function
delaying the splash-screen
etc.
这三条规则对我来说效果很好。
答案 13 :(得分:0)
我建议在生产模式下调试PHP代码的方法。
免费注册并在http://todell.com/debug
像这样调试你的php代码
定义( “DEBUG_LVL”,1); / *将其放置在任何方便编辑的位置或整个Web应用程序中包含的单个文件中。 * /
if(DEBUG_LVL&gt; 0) 的file_get_contents( “http://todell.com/w/y/ //”。用urlencode(json_encode($对象))。 “/”。订单即可。 “/”。用urlencode(的文件)。 “/".$_ SERVER [” REMOTE_ADDR“]);
$ object 是您要发送到调试应用的对象。它可以是从您的代码抛出的异常或基准数据中的任何内容。 $ object大小限制为64KB 这不仅限于PHP语言。
答案 14 :(得分:0)
我只会提到这一点,因为没有人去过那里。
如果您不编写任何调试代码,则调试代码将无法生成。
如果您正在编写“调试代码”,则表明您实际上并未理解您的代码。也许它太复杂了。
首先编写单元测试。这种做法将导致更好的设计。确保您拥有完整的代码覆盖率。测试难以发生的情况 - 无法获得套接字连接,数据库不可用等。编写回归测试。不要部署任何无法通过它们的东西。在更改代码之前,应将任何错误报告转换为回归测试。回归测试应该失败 - 并且是唯一失败的测试。修复错误。
自动编译和测试。如果您实际编写调试代码,则应在测试成功后立即删除它。当您的组织真正成熟时,您甚至可以自动部署。
答案 15 :(得分:-1)
开发人员的勤奋和优秀的测试人员确实阻碍了这一切。没有任何单一的工具或流程可以防止这种情况发生。
如果有的话,这是一个很好的例子,说明为什么一个非痛苦的构建/部署过程至关重要。不好的事情会进入生产。保证。真正的问题不是如何预防它,而是如何应对它。