私のお気に入りのプログラミングミス

プログラマーとしてのキャリアの中で、私はいくつかの異なる言語で膨大な数の間違いを犯しました。 実際、最初に機能するコードを10行以上記述すると、疑わしくなり、構文のエラー、配列への誤った参照、または誤って記述された変数を見つけることを想定して、通常よりも慎重にテストを開始します。他の何か。



これらのエラーを、障害、エラー、欠点の3つの大きなグループに分けたいと思います。 失敗は、画面を見て愚かに座って静かに「ああ」と言うときです。 データベースやサイト全体を削除したり、3日間の仕事の結果の上に何かを書いたり、誤って2万人に手紙を送ったりといったことです。



エラーは異なる場合があります：単純な構文エラー（たとえば、忘れる}）から重大なエラーや計算のエラーまで。



間違いがあまりにも明白でわかりにくいためにほぼ完璧な場合、私はそれを欠陥と呼びます。 これは、コードの一部が完全に予測不可能で非常にまれな状況に直面したときに発生します。 あなたは後ろに寄りかかって、「すごい！」と考えます。まるで明るい虹や流れ星を見ているかのようです。

デバッグモードがオフになっていない

この記事で言及する最初の2つのエラーは、完全な失敗でした。



フリーランスを始めたとき、データベースクエリ、フォーム、およびページテンプレートを処理するためのPHPライブラリをいくつか作成しました。 デバッグモードは、グローバル変数$ DEBUGに依存するかなり深いレベルでライブラリに組み込まれました。



また、開発、デバッグ、およびテストのために作業したすべての主要なサイトのローカルコピーを保持しました。 したがって、問題が発生したときは、常に$ DEBUG = 1に設定できました。 たとえば、すべての実行可能なデータベースステートメントなど、さまざまなことを教えてくれました。 私は、オンラインサイトでこのエラー検出方法を使用することはほとんどなく、ローカルでの使用を目的としています。



しかしある日、私は夜遅くまで働いて、ある人気のあるeコマースサイトの小さな問題を修正しました。 $ DEBUG = 1に設定しました。 いくつかのページの上部で、それらの間で切り替えました。 私の頭の疲れから、すべてが混ざり合い、最終的にはサイトの最も重要なページにデバッグ変数を追加しました。ユーザーは「今すぐ支払う」ボタンをクリックするとすぐに表示され、このフォームでサイトの作業バージョンにアップロードされました。



翌朝、私は早めに家を出て、午後9時に戻ってきましたが、留守番電話に12通のメッセージがあり、もう1通は迷惑で、さらに多くの電子メールがありました。 約20時間、「今すぐ支払う」をクリックしたユーザーは次のようなものを見ました。



エラーを修正するのにたった10秒しかかかりませんでしたが、注文を逃した1日中、クライアントに謝罪するのにより多くの時間がかかりました。

学んだ教訓

私はこのケースを熟考し、次のことがわかった。

1.深夜に仕事をしない

2.注文処理に少しでも変更を加えるたびに完全なテストを実施する

3.デバッグレポートがライブサイトに表示されないようにします

4.緊急時の連絡先情報を顧客に提供します。

注意深いデバッグ

3番目のポイントに関連して、デバッグメッセージの表示が自分だけに表示されるように、いくつかの関数を作成しました。

 function CanDebug() { global $DEBUG; $allowed = array ('127.0.0.1', '81.1.1.1'); if (in_array ($_SERVER['REMOTE_ADDR'], $allowed)) return $DEBUG; else return 0; } function Debug ($message) { if (!CanDebug()) return; echo '<div style="background:yellow; color:black; border: 1px solid black;'; echo 'padding: 5px; margin: 5px; white-space: pre;">'; if (is_string ($message)) echo $message; else var_dump ($message); echo '</div>'; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

$許可された配列には、ローカルテスト用のIPアドレス（127.0.0.1）と外部IPが含まれています。

次のように出力できます：

 $DEBUG = 1; Debug ("The total is now $total"); //about a debugging message Debug ($somevariable); //output a variable Debug ("About to run: $query"); //before running any database query mysql_query ($query);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、私以外の誰にもデバッグメッセージが表示されないようにします。 上記の変数が指定されている場合、コードは次のようになります。



セキュリティを強化するために、HTMLコメント内にエラーメッセージを転送することもできますが、適切な部分を見つけるには長い間コードを掘り下げる必要があります。

すべてのPHP通知、警告、エラーが自分だけに表示されるように、ページまたは構成ファイルの上部に配置できる別の便利なコードがあります。 エラーと警告はログに記録されますが、画面には表示されません。

 if (CanDebug()) {ini_set ('display_errors', 1); error_reporting (E_ALL);} else {ini_set ('display_errors', 0); error_reporting (E_ALL & ~E_NOTICE);}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デバッガー

このような方法は、厳密に定義されたコードフラグメントのエラーをすばやく見つけるのに便利です。 FirePHPやXdebugなど、コードに関する豊富な情報を提供できるさまざまなデバッグツールもあります。 また、ユーザーに表示せずに、すべての関数呼び出しをログファイルに一覧表示して、見えないように動作させることもできます。 Xdebugは次のように使用できます。

 ini_set ('xdebug.collect_params', 1); xdebug_start_trace ('/tmp/mytrace'); echo substr ("This will be traced", 0, 10); xdebug_stop_trace();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードは、すべての関数呼び出しとそのパラメーターを/tmp/mytrace.xtファイルに登録します。これは次のようになります。



Xdebugは、PHPの警告またはエラーに関するより多くの情報も表示します。 ただし、サーバーにインストールする必要があるため、ほとんどのホスティング会社ではこれを実行できない可能性があります。

一方、FirePHPは、Firebugアドオンと相互作用するPHPライブラリーとして機能します。 デバッグ情報をPHPからFirebugコンソールに直接出力できます。これもユーザーには表示されません。

どちらの方法でも、上記のCanDebugのような関数は、Firebugのすべての所有者がスタックトレースとログファイルの作成にアクセスできないようにするのに役立ちます。

デバッグモードをオフにする

電子メールスクリプトのデバッグはより複雑です。 スクリプトが正しい方法で電子メールを送信しているかどうかを確認することは、実際に電子メールを送信することなく間違いなく困難です。 それは私がかつて誤ってやったことです。



数年前、私は毎日2万人以上の加入者に電子メールを送信するための大規模な電子メールスクリプトを作成するように求められました。 開発中に、CanDebug関数に似たものを使用して、電子メールを送信せずにスクリプトをテストできました。 電子メール送信機能は次のようになりました。

 function SendEmail ($to, $from, $subject, $message) { if (CanDebug() >= 10) Debug ("Would have emailed $to:\n$message"); else { if (CanDebug()) {$subject = "Test to $to: $subject"; $to = "test@test.com";} mail ($to, $subject, $message, "From: $from"); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

$ DEBUG = 1に設定すると、スクリプトはテストアドレスに電子メール（すべて2万件）を送信し、確認できました。 $ DEBUG = 10に設定した場合、彼は電子メールを送信しようとしていると通知しましたが、実際には何も送信しませんでした。 スクリプトを開始して間もなく、問題が始まりました。 彼は、低パフォーマンスの情報処理が20,000回連続して実行されたため、メモリ不足になったと思います。 ある時点で、ある種のエラーを修正しようとし、$ DEBUG変数（または間違った時間に外部IPが変更された）を忘れて、誤って2万人に手紙を送りました。



私が働いていた代理店に謝罪しましたが、幸いなことに特に影響はありませんでした。 おそらく、多くの文字がスパムフィルターによってブロックされました。 または、受信者は、手紙が空であることに単純に満足していたかもしれません。

学んだ教訓

手紙の主題と内容として単に「テスト」という言葉を残したことは非常にうれしく、発生したバグに対する不満を反映した声明ではありません。 必要なものを学びました：

1.バルクメールスクリプトをテストする場合は特に注意してください-デバッグモードが機能しているかどうかを確認してください。

2.できるだけ少ない人にテストメールを送信します。

3.手紙の本文には、「このテストメッセージを無視してください」など、常に丁寧なものを書いてください。 「私のクライアントはバカです」のようなものを書くのは望ましくありません-疑いを持たない2万人の投資家がそれを読むかどうかはわかりません。

PHPの空白ページ

今、私たちは失敗の王国から微妙な間違いの領域に到達しました。 取り除くのが難しいエラーを見たい場合は、コードの深さのどこかに以下を埋めてください。

 function TestMe() {TestMe();} TestMe();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ブラウザとサーバー上のApacheとPHPのバージョンによっては、空白ページ、「このWebページは利用できません」、メモリ不足による重大なエラー、または「保存」または「開く」ページ文が表示される場合があります。



これは本質的に無限再帰を引き起こし、メモリ不足やサーバースレッドクラッシュを引き起こす可能性があります。 動作を停止すると、エラーログに小さなトレースが残る場合があります。

[2011年6月6日18:24:10] [通知]子pid 7192

終了信号セグメンテーション障害（11）

これにより、エラーが発生した場所と理由がわかります。 また、問題のあるコードが実行される限りページ全体が機能しないため、さまざまな場所に出力行を追加するすべてのクイックデバッグメソッドは、特別な結果をもたらしません。 基本的に、これはPHPが生成されたHTMLを定期的にのみブラウザに送信するためです。 したがって、多くの式を追加すると、flush（）; 少なくとも、再帰エラーの直前にスクリプトが何をしたかを示します。

もちろん、このエラーの原因となるコードは、上記のコードよりもはるかに洗練されている場合があります。 元のクラスを参照する他のクラスのクラスを呼び出すメソッドが含まれる場合があります。 そして、このエラーは、再現が困難な状況でのみ発生する可能性があります。

学んだ教訓

1.何かがそこに書き込まれた場合に備えて、エラーログの場所を把握します。

2.このような状況では、Xdebugのようなスタックトレースデバッガーは非常に便利です。

3.それ以外の場合は、すべてのコードを1行ずつ調べて、機能するまで不要な部分をコメントアウトするための時間を大幅に節約します。

無効な変数タイプ

このエラーは、多くの場合データベースで発生します。 これらのSQLステートメントが与えられた場合...

 CREATE TABLE products ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(60), category VARCHAR(10), price DECIMAL(6,2) ); INSERT INTO products VALUES (1, 'Great Expectations', 'book', 12.99); INSERT INTO products VALUES (2, 'Meagre Expectations', 'cd', 2.50); INSERT INTO products VALUES (3, 'Flared corduroys', 'retro clothing', 25);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

...以下を実行すると何が返されると思いますか？

 SELECT * FROM products WHERE category='retro clothing';
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

カテゴリ列の長さは10文字しかないため、答えは何もありません。そのため、最後の製品のカテゴリはレトロクロットになります。 最近変更された製品や新しいメニュー項目の突然の消失は、非常に混乱する可能性があります。 しかし、通常これはかなり簡単に修正できます。

 ALTER TABLE products MODIFY category VARCHAR(30); UPDATE products SET category='retro clothing' WHERE category='retro clot';
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の主要なeコマースサイトで作業しているときに、より深刻なミスを犯しました。 注文プロセスの最後に、サイトはクライアントにクレジットカードの詳細を入力するように要求し、バークレイズePDQシステムに支払い要求を送信するJavaプログラムを呼び出しました。 金額は年金で計算されました。 私はJavaに精通していなかったので、基礎として見つかったコードサンプルを取りました。

短い合計;

Javaプログラムはコマンドラインから呼び出されました。 彼女が何も返さなかった場合、トランザクションは完了したとみなされ、クライアントは電子メールを受信し、注文は完了しました。 クレジットカードの確認中にエラーが発生した場合、プログラムは「カードは認証されていません」または「カードは認証に失敗しました」などのメッセージを返しました。

短整数には、-32768〜+32767の値を格納できます。 これらの数字は巨大に見えました。 しかし、私は金額がポンドではなくペンスで計算されたという事実に注意を払いませんでした。つまり、可能な最大額は327.67ポンドでした。 そして最悪なのは、注文金額がこれを超えると、Javaプログラムが機能しなくなり、何も返されないことです。 注文が正常に完了したように見え、その後、通常どおり購入プロセスが進行しました。 このエラーは、数か月後の大量の未払い注文の後、経理部、または用心深く誠実なバイヤーによって気づかれました。

学んだ教訓

1.データベースまたは変数の列に型を割り当てる場合、慎重に行う必要があります。

2.プログラムの正常な完了が、動作を停止するプログラムと異なることを確認する必要があります。

「ペニーのエラー」

私のお気に入りの間違いは、わずか1ペニー（セント、時代、または他のコイン）の不一致を引き起こすものです。 追跡が非常に難しく、しばしば丸め誤差が生じるため、私はそれらが好きです。

数年前、私はお金を表示する1つのサイト用の簡単なJavaScript関数を作成する必要がありました。 私はこれを使用しました：

 <script type="text/javascript"> function GetMoney (amount) {return Math.round (amount * 100) / 100;} </script>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、1.20のような量が1.2の形で画面に表示されることがすぐに明らかになりました。 だから私はこのようにコードを変更しました：

 <script type="text/javascript"> function GetMoney (amount) { var pounds = Math.floor (amount); var pence = Math.round (amount * 100) % 100; return pounds + '.' + (pence < 10 ? '0' : '') + pence; } </script>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

主な違いは、最後の行の余分な0です。 しかし、ペニーは個別に計算されるため、数量を100で割ったときに残りを取得するには％演算子が必要です。このコードでエラーが発生する可能性の低い状況を見つけてください。

これは、ビーズを販売したサイトで発生しました。 その後、ビーズは、分数の値を含むカスタムブレンドを含め、さまざまな形や数量で販売できることがわかりました。 顧客が4.95ポンド相当の1.01品目を購入し、4.00ポンドのみを支払った場合。 金額は4.9995と定義されているため、プログラムはペンスを100に丸め、％100は0ペンスを残しました。 したがって、支払額は4ポンドに減少しました。



丸み付けの単純な欠陥。100個あたり4.95ポンドで販売された101個のビーズに対して、5ポンドではなく4ポンドを支払いました。

私はすぐにコードを修正しました：

 <script type="text/javascript"> function GetMoney (amount) { var pounds = Math.floor (amount); var pence = Math.floor (amount * 100) % 100; return pounds + '.' + (pence < 10 ? '0' : '') + pence; } </script>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、これは4.9995ポンドから4.99ポンドに切り上げられたため、サーバーからの対応する計算との同期が妨げられたため、適切な修正ではありませんでした。 さらに悪いことに、£1.00相当の0.7を注文した場合、金額は70ペンスから69ペンスになりました！ これは、0.7のような浮動小数点数が0.6999999999999999ではなく2進数で表示され、70に丸める代わりに69ペンスに削減されるためです。

これは本当の「一ペニーの間違い」です。 それを修正するために、最初に別の丸めを追加しました。

 <script type="text/javascript"> function GetMoney (amount) { var pence = Math.round (100 * amount); var pounds = Math.floor (pence / 100); pence %= 100; return pound + '.' + (pence < 10 ? '0' : '') + pence; } </script>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、非常に単純な1つのことを行うために、非常に複雑な4行のコードができました。 今日、私はこの記事を書いているときに、これらすべてを処理できるJavascriptに組み込まれた関数を見つけました。

 <script type="text/javascript"> function GetMoney (amount) {return amount.toFixed (2);} alert (GetMoney (4.9995) + ' ' + GetMoney (0.1 * 0.7)); </script>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PayPalで割引を提供する

PayPalは「一ペニーの間違い」であり、翼の中で待っています。 多くのサイトでは、注文金額の特定の割合の割引を提供するコードを提供しています。 最後に計算されます。 95ペンスで2つのアイテムを注文した場合、合計金額は£1.90になり、19ペンスの割引を受けるため、£1.71を支払います。

ただし、PayPalはこのタイプの割引をサポートしていません。 PayPalで買い物かごに商品を表示する場合は、それぞれの商品の価格と数量を個別に計算する必要があります。

 <input name="item_name_1" type="hidden" value="My Difficult Product" /> <input name="amount_1" type="hidden" value="0.99" /> <input name="quantity_1" type="hidden" value="1" />
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、アイテムごとに個別に割引を受ける必要があります。 95ペンスから10％割引すると、85.5ペンスになります。 PayPalは小数では動作しないため、86ペンスに丸める必要があります。これにより、PayPalの合計金額は£1.72になります。 85pに切り上げた場合、合計金額は£1.70になります。

この問題を解決するには、各アイテムの割引を個別に計算する必要もありました。 通常の10％×£1.90の計算の代わりに、コードは、ペンスの全額を使用するたびに、アイテムからアイテムへの割引を累積します。 $アイテムが注文アイテムのPHP配列であると仮定します：

 $discount = 0; $discountpercent = 10; foreach ($items as $item) { $mydiscount = floor ($item->price * $discountpercent) / 100; $item->priceforpaypal = $item->price - $mydiscount; $discount += $mydiscount * $item->quantity; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

学んだ教訓

1.単純な外観の非常に小さな車輪であっても、車輪を再発明しないでください。

2. 1ペニーの差がある場合は、数字がどこでどのように丸められているかを確認します。

3.可能であれば、フロート変数で価格を提示しないでください。 代わりに、ペンスとセントに整数を使用し、データベースでは固定小数点変数のタイプDECIMALを使用します。

時計の変更

このエラーを「エラー」とは呼びません。 特別なまれな状況下で表示されるため、プログラマーの観点からは、これは「欠陥」である可能性が高くなります。 プログラマーが提供できるすべてを超えています。

一週間以上前に完了した注文を強調するこの一見無害なコード行の何が問題なのか推測できますか？

 mysql_query ("SELECT * FROM orders WHERE completeddate < '" . date ('Ymd H:i:s', (time() - 7 * 86400 + 600)) . "'")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

定期的な週次注文には、システムで同様の行を使用しました。 彼女は先週行われた注文を選択し、それらを複製して、今週に注文を出しました。 86,400は1日の秒数であるため、時間（）-7 * 86400はちょうど1週間前であり、+ 600は10分の空き時間を追加します。

これは、繰り返し注文を実装する低コストの方法でした。 時間があれば、別のテーブルや買い物かごを作成して、繰り返される注文と繰り返されない注文を区別します。 このコードは数か月間は問題なく機能し、3月末には謎の理由で失敗したことが判明しました。

欠陥の解消とその結果には多くの時間がかかり、注文を手動で実行する必要がありました。 原因を特定するのにさらに時間がかかりました。特に、敷地全体を別の日だと考えるようにサイト全体に強制する必要があったためです。

一般に、セクションのタイトルでその理由についてすでに説明しました。1週間が7 * 86400秒未満の場合、時間の夏時間への変換を考慮するのを忘れていました。

次の3つの方法を比較して、ちょうど1週間前に取得します。 後者が最もエレガントです。 私は最近それを発見しました：

 $time = strtotime ('28 March 2011 00:01'); echo date ('Ymd H:i:s', ($time - 7 * 86400)) . '<br/>'; echo date ('Ymd H:i:s', mktime (date ('H', $time), date ('i', $time), 0, date ('n', $time), date ('j', $time) - 7, date ('Y', $time))); echo date ('Ymd H:i:s', (strtotime ('-1 week', $time))) . '<br/>';
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

学んだ教訓

このようなエラーから一般的な結論を引き出すことは困難ですが、特定の教訓が得られました。

1.繰り返しの多いサイトでは、タイムゾーンとクロックを考慮することを忘れないでください。

2.繰り返しますが、車輪を再発明しないでください。

おわりに

プログラミングのエラーにはさまざまな形とサイズがあります。 この記事では、それらは非常に明白な失敗から信じられないほど微妙な誤算にまで及びます。 そして、彼ら全員がマーフィーの法則を確認しているようです。トラブルが起こる可能性がある場合、それは起こります。



ただし、検出、報告、修正されるエラーごとに、コードにいくつかのエラーが残る場合があります。 それらが見つからない可能性があります（原因となる異常な状態が再現されていないため）、それらは報告されない可能性があります（ほとんどのユーザーがエラーレポートを送信することに煩わされないため）、または不必要なお金や時間のために修正されないコスト。



さらに、エラーは人気のあるサイトでより一般的です-主に多くの人々によって作られているためですが、1つのエラーを修正すると他の場所に新しいエラーが現れる可能性があるためです。 したがって、先を見越して、エラーを注意深く修正する必要があります。