JavaScriptでビデオプレーヤーを作成しているとします。このビデオプレーヤーは、再帰関数を使用してユーザーのビデオを繰り返しループします。そのため、ブラウザーはいつかトリガーしtoo much recursion RangeErrorます。

おそらくループ機能をそれほど使用する人はいないでしょう。ユーザーがアプリケーションを1週間ループしたままにしたとしても、アプリケーションはこのエラーをスローしませんが、まだ存在します。問題を解決するには、アプリケーションでループが機能する方法を再設計する必要がありますが、これにはかなりの時間がかかります。職業はなんですか？どうして？

• バグを修正する

• バグを残す

人々がつまずくバグを修正するだけではいけませんか？バグ修正がいつ過剰になりますか？

編集：

実際のバグを引き起こさない再帰的なアプローチが懸念事項である場合、プレーヤーがビデオをループするたびに変数が増加すると仮定します1。2 ⁵³ループ後、この変数はオーバーフローし、プログラムはそれを処理できなくなり、例外をスローします。

あなたは実用的でなければなりません。

エラーが現実の世界で引き起こされる可能性が低く、修正にかかるコストが高い場合、多くの人々がそれを修正するためのリソースの適切な使用と考えるとは思わないでしょう。それに基づいて、私はそれを残すと言いますが、数ヶ月以内にあなたまたはあなたの後継者のためにハックが文書化されることを確認します（最後の段落を参照）。

ただし、この問題は「学習体験」として使用する必要があります。次回ループを実行するときには、不必要に再帰ループを使用しないでください。

また、そのバグレポートに備えてください。エンドユーザーが境界に立ち向かい、欠陥を発見するのにどれほど優れているか、驚くでしょう。エンドユーザーにとって問題になる場合は、修正する必要があります。ハックを文書化していただければ幸いです。

49 .7 日後にコンピューターがクラッシュする原因となるWindows 95の同様のバグがありました。とにかくそのように長く滞在したWin95システムはごくわずかだったため、リリースから数年後にしか気付きませんでした。つまり、1つのポイントがあります。バグは、他のより重要なバグによって無関係になる可能性があります。

あなたがしなければならないことは、プログラム全体のリスク評価と個々のバグの影響評価です。

• このソフトウェアはセキュリティ境界にありますか？
• もしそうなら、このバグはエクスプロイトにつながる可能性がありますか？
• このソフトウェアは、対象ユーザーにとって「ミッションクリティカル」ですか？（Java EULAがを使用することを禁止しているもののリストを参照してください）
• バグによりデータが失われることはありますか？財務上の損失？評判の低下？
• このバグはどの程度発生する可能性がありますか？（これをシナリオに含めました）

等々。これは、バグのトリアージ（修正するバグを決定するプロセス）に影響します。ほとんどすべての出荷ソフトウェアには、修正するのに十分重要であるとまだ見なされていないマイナーなバグの非常に長いリストがあります。

他の答えはすでに非常に優れており、あなたの例は単なる例にすぎませんが、まだ議論されていないこのプロセスの大部分を指摘したいと思います。

前提条件を特定し、それらの前提条件をコーナーケースに対してテストする必要があります。

あなたの例を見ると、いくつかの仮定があります：

• 再帰的なアプローチは、最終的にエラーを引き起こします。
• ビデオはスタック制限に達するまで再生に時間がかかりすぎるため、このエラーは誰にも表示されません。

他の人々は最初の仮定を議論しましたが、2番目の仮定を見てください：私のビデオがほんの一瞬の長さならどうでしょうか？

確かに、それはあまり一般的な使用例ではありません。しかし、非常に短いビデオを誰もアップロードしないと本当に確信していますか？あなたはビデオが最小の時間であると仮定している、そして、あなたはおそらくあなたが何かを仮定していることにさえ気付かなかったでしょう！この仮定は、アプリケーションの他の場所に他のバグを引き起こす可能性がありますか？

不明な仮定はバグの巨大な原因です。

私が言ったように、あなたの例は単なる例であることを知っていますが、あなたの仮定を特定し（それは思ったよりも難しいことが多い）、それらの仮定の例外を考えるこのプロセスは、あなたの時間を過ごす場所を決める大きな要因です。

したがって、「これは絶対に起こらないので、これをプログラムする必要はない」と考えている場合は、その仮定を実際に調べるのに少し時間をかける必要があります。多くの場合、最初に考えていたよりも一般的なコーナーケースを考えます。

そうは言っても、これが無益さの練習になるポイントがあります。JavaScriptアプリケーションがTI-89計算機で完全に動作するかどうかは気にしないので、そのために時間を費やすだけで無駄になります。

他の答えはすでにこれをカバーしていますが、「これは重要です」と「これは時間の無駄です」の間の線を考え出すことは正確な​​科学ではなく、それは完全に異なることができる多くの要因に依存します別の人または会社。

しかし、そのプロセスの大部分は、最初に仮定を特定し、次にそれらの仮定の例外を認識しようとすることです。

次の論文を読むことをお勧めします。

信頼性とその脅威：分類

特に、プログラムで発生する可能性のあるさまざまなタイプの障害について説明します。あなたが説明したものは休眠障害と呼ばれ、本書では次のように説明します。

フォールトは、エラーを生成するときにアクティブになり、そうでない場合は休止状態になります。アクティブな障害は、a）以前に休止状態で、計算プロセスまたは環境条件によってアクティブにされた内部障害、またはb）外部障害のいずれかです。フォルトアクティベーションとは、休止フォルトをアクティブにするコンポーネントへの入力（アクティベーションパターン）の適用です。ほとんどの内部障害は、休止状態とアクティブ状態の間を循環します

これを説明してから、それはすべて費用便益比に要約されます。コストは3つのパラメーターで構成されます。

• 問題はどのくらいの頻度で発生しますか？
• 結果はどうなりますか？
• 個人的にどれだけ気になりますか？

最初の2つは重要です。一度ブルームーンに現れたり、誰も気にしないバグである場合、または完全に適切で実用的な回避策がある場合は、それを既知の問題として安全に文書化し、より挑戦的でより多くの問題に進むことができます重要なタスク。ただし、バグが原因で金銭取引が失敗したり、長い登録プロセスが中断されてエンドユーザーがいらいらしたりする場合は、それに対処する必要があります。3番目のパラメーターは、私が強くお勧めするものです。Vito Corleoneの言葉では：

それは個人的なものではありません。それはビジネスです。

あなたがプロなら、感情を脇に置き、最適に行動します。ただし、作成しているアプリケーションがあなたの趣味である場合、感情的に関与しており、3番目のパラメーターは、バグを修正するかどうかを決定する点で有効です。

そのバグは、誰かが会社のプレゼンテーションを24時間年中無休で実行しているロビー画面にプレイヤーを置く日まで発見されないままです。まだバグです。

答え何をしますか？実際にはビジネス上の決定であり、エンジニアリング上の決定ではありません。

• バグがユーザーの1％にのみ影響し、プレーヤーがさらに20％が必要とする機能をサポートしていない場合、選択は明らかです。バグを文書化してから続行してください。
• バグ修正がToDoリストに含まれている場合、多くの場合、新しい機能を追加する前に修正することをお勧めします。欠陥のないソフトウェア開発プロセスのメリットを享受できます。とにかくリストに載っているため、多くの時間を無駄にすることはありません。

特に大企業（または大規模プロジェクト）では、何をすべきかを確立するための非常に実用的な方法があります。

修正のコストが修正がもたらすリターンよりも大きい場合は、バグを保持します。修正プログラムがそのコストよりも多くを返す場合は、その逆でバグを修正します。

サンプルシナリオでは、費用のかかるバグを修正するのではなく、新機能を開発する場合に失うと予想されるユーザー数と獲得するユーザー数に依存します。

tl; drこれが理由RESOLVED/WONTFIXです。使いすぎないでください。注意を怠ると、技術的な負債がたまります。これはデザインの根本的な問題であり、将来的に他の問題を引き起こす可能性がありますか？それを修正します。そうでなければ？優先度が上がるまでそのままにしておきます（これが優先される場合）。

説明した状況には、実際には3つのエラーがあります。

1. ログに記録されたすべてのエラーを評価するプロセスがない（チケット/バックログ/設置されているシステムにエラーを記録しましたか？）。修正すべきかどうかを判断します。これは管理上の決定です。

2. このような障害のあるソリューションの使用につながるチームのスキルの欠如。これは、将来の問題を回避するために対処することが急務です。（あなたの間違いから学び始めてください。）

3. 非常に長い時間が経過すると、ビデオの表示が停止する可能性があるという問題。

3つのエラーのうち（3）のみを修正する必要はありません。

ここには、バグを残すのではなく、修正されるバグのコストを評価することについて議論する多くの答えがあります。それらはすべて良いアドバイスを含んでいますが、バグのコストはしばしば過小評価されており、恐らく非常に過小評価されていることを付け加えたいと思います。その理由は、既存のバグが継続的な開発と保守のために水域を混乱させるためです。テスターに​​いくつかの「修正できない」バグを追跡させ、新しいバグを見つけようとしてソフトウェアをナビゲートすると、作業が遅くなり、エラーが発生しやすくなります。エンドユーザーに影響を与えそうにないいくつかの「修正しない」バグは、継続的な開発をさらに遅くし、結果はバグが増えます。

長年のコーディングで学んだことの1つは、バグが再発することです。エンドユーザーは常にそれを発見し、報告します。バグを修正するかどうかは、「単なる」優先事項であり、期限の問題です。

エンドユーザーが何度も何度もつまずいたために、次のリリースのショーストッパーになるだけで、1つのリリースで修正することを決定された大きなバグ（私の意見ではメジャー）がありました。同じ逆-私たちは誰も使用していない機能のバグを修正するようにプッシュされましたが、管理者が見るのは便利でした。

ここには3つのことがあります。

原則

これはコインの片側です。ある程度まで、誰も気づいていないとしても、バグの修正（または、それらが「機能する」としても悪い実装）を主張するのは良いと感じています。

このように見てください。実際の問題は、必ずしもあなたの例のバグではなく、プログラマーがそもそもこの方法でループを実装するのは良い考えだと思ったという事実です。これが良い解決策ではないことは、最初の瞬間から明らかでした。現在、2つの可能性があります。

• プログラマーは気づきませんでした。まあ...プログラマは自分のコードがどのように実行されるかの直感を開発する必要があります。再帰は非常に難しい概念ではありません。バグを修正する（およびすべての追加作業を繰り返す）ことで、将来の追加作業を回避するためだけに、彼は何かを学び、それを覚えているかもしれません。理由が彼に十分な時間がなかったためである場合、管理者はプログラマがより高品質のコードを作成するためにより多くの時間が必要であることを知るかもしれません。

• プログラマーは気づきましたが、「問題ではない」と考えました。これが放置されると、最終的には本当に痛いバグにつながる自由放任主義の文化が発達します。この特定のケースでは、誰が気にします。しかし、そのプログラマーが次回銀行業務アプリケーションを開発し、特定の星座が決して起こらないと決定した場合はどうでしょう。それから。悪い時代。

プラグマティズム

これは反対側です。コースあなたはおそらく、この特定のケースでは、バグを修正しないでしょう。しかし、気をつけてください-プラグマティズムがあり、そしてプラグマティズムがあります。優れたプラグマティズムは、問題に対する迅速でありながらしっかりとした、しっかりとした解決策を見つけた場合です。つまり、過剰な設計を避けますが、実際に実装するものはまだよく考え抜かれています。悪いプラグマティズムとは、何かを一緒にハッキングして、「うまくいく」ようにし、最初の機会に壊れる場合です。

速く失敗し、激しく失敗する

疑わしい場合は、速く失敗し、激しく失敗します。

これは、とりわけ、コードが環境ではなくエラー状態に気付くことを意味します。

この例では、自分でハード例外に置き換えることにより、ハードランタイムエラー（「スタックの深さを超えた」など）が発生しないようにすることができます。たとえば、グローバルカウンターを使用して、1000本のビデオ（または通常の使用では発生せず、ほとんどのブラウザーで動作するのに十分低い数）の後に救済することを任意に決定できます。次に、その例外（RuntimeExceptionJavaのような一般的な例外、またはJavaScriptやRubyの単純な文字列など）に意味のあるメッセージを渡します。新しい種類の例外を作成するために、または特定のプログラミング言語で行うことをするために、範囲に行く必要はありません。

このように、あなたは持っています

• ...コード内の問題を文書化しました。
• ...確定的な問題にしました。あなたはあなたの例外が起こることを知っています。基盤となるブラウザーテクノロジーの変化に気付いていません（PCブラウザーだけでなく、スマートフォン、タブレット、または将来の技術についても考えてください）。
• ...最終的に修正が必要になったときに、簡単に修正できるようにしました。問題の原因はあなたのメッセージによって指摘されており、あなたは有意義なバックトラックとそのすべてを得るでしょう。
• ...「本物の」エラー処理を行う時間を無駄にしません（エラーが発生することは決してありません）。

私の慣例では、このようなエラーメッセージの前に「Paranoia：」という単語を付けます。これは、私や他のすべての人にとって、そのエラーが飛び出すことを決して期待しないという明確な兆候です。それらを「実際の」例外から明確に分離できます。GUIまたはログファイルでそのようなものを見つけた場合、私は深刻な問題があることを確かに知っています-結局、それらが起こるとは思っていませんでした。で、この時点私は（私は、問題が発生した場所を正確に知っているように、スプリアスデバッグの多くから私を保存し、簡単に素早く、むしろそれを解決する良い機会と）クランチモードに入ります。

私の職場の上級開発者の机の上のポストイットは言う

それは誰にも役立ちますか？

多くの場合、それは思考プロセスの良い出発点だと思う。修正と改善が必要なものは常にたくさんありますが、実際にどれだけの価値を追加していますか？...それは、使いやすさ、信頼性、保守性、可読性、パフォーマンスなど、その他の側面に関係します。

3つのことが思い浮かびます。

最初に、特定されたバグの影響を徹底的に調査してから、コードにバグを残すという決定を責任ある方法で行う必要があります。（あなたの例では、私は一度に表し増え続けるスタックを漏らすと遅く、遅く各再帰でブラウザを作る可能性のあるメモリを考えました。）この徹底した調査では、多くの場合、長いので、私は固定を好むだろうバグを修正よりも時間がかかりますほとんどの場合、バグ。

第二に、バグは最初に考えるよりも大きな影響を与える傾向があります。これは「通常の」ケースであるため、私たちは作業コードに非常に精通しています。一方、バグは「例外」です。もちろん、多くのバグを見てきましたが、全体としてより多くのコードが動作するのを見てきました。したがって、バグのあるコードの動作よりも、動作するコードの動作の方が多くの経験があります。作業コードとそれがどのような状況で何をするかについての膨大な本があります。バグのあるコードの動作についてはほとんどありません。

その理由は簡単です。バグは秩序ではなく混乱です。彼らにはしばしば注文の痕跡が残っています（または逆に言えば、注文を完全に破壊するわけではありません）が、バグの多い性質はプログラマーが望んだ注文の破壊です。カオス自体は、正しく推定されることに抵抗する傾向があります。バグのあるプログラムが何をするかを言うのは、正しいプログラムが何をするかということよりも、それが精神パターンにもはや適合しないという理由だけで言うのははるかに困難です。

第三に、あなたの例には、バグを修正するとプログラムの再設計が必要になるという側面が含まれていました。（この側面を取り除く場合、答えは簡単です：バグを修正し、再設計の必要がないため、それほど時間がかからないはずです。それ以外の場合:)そのような場合、現在設計されている方法でプログラムに対する信頼を失います。再設計は、その信頼を回復する方法です。

とは言っても、プログラムは人々が使用するものであり、機能の欠落や2番目の面倒なバグは、バグの修正よりも優先される可能性があります。もちろん、実際的な方法で他のことを最初に行います。しかし、バグの影響の最初の迅速な推定が完全に間違っている可能性があることを忘れないでください。

低確率/軽度の結果=低優先順位修正

• 発生の確率が非常に低い場合
• 発生の結果が軽度の場合
• その場合、バグは脅威にならず、優先順位の修正ではありません。

しかし、これは怠zyな開発者にとって松葉杖になることはできません...

• 「非常に低い発生率」とはどういう意味ですか？
• 「軽度の結果」とはどういう意味ですか？

発生の可能性が非常に低く、結果が軽度であると述べるには、開発チームはコード、使用パターン、およびセキュリティを理解する必要があります。

ほとんどの開発者は、元々考えていたことが決して起こらないことに驚き、実際には多くのことが起こります

私たちの教育システムは、確率と論理をうまく教えていません。ほとんどのソフトウェアエンジニアを含むほとんどの人は、壊れた論理と壊れた直感を持っています。これを解決する唯一の方法は、現実の問題の経験と広範なシミュレーションの経験です。

現実世界のデータで直観に立ち向かう

使用パターンに従うことができるように、いくつかのログを作成することが重要です。起こるべきではないと思うことの表明でコードを埋めてください。あなたは彼らがそうすることに驚くでしょう。そうすれば、直観にハードデータを突き付けて洗練させることができます。

軽度の問題と制御の尺度の私の例

私がずっと前に仕事をしたeコマースサイトで、別のプログラマーがミスを犯しました。ある曖昧な状況で、システムがログに登録されているより1パーセント少ないクライアントに借方記入しました。バグを発見したのは、会計システムの回復力を高めるために、ログとアカウントのバランスの違いを特定するレポートを作成したためです。違いが非常に小さいため、このバグを修正したことはありません。差異は毎日計算され、毎月2.00米ドル未満でした。まったく新しいシステムを開発していたので、1年後には現在のシステムを置き換える必要があります。収益性の高いプロジェクトからリソースを流用して、毎月2.00米ドルの費用がかかり、適切な管理基準が適用されたものを修正する意味はありません。

結論

はい、すぐに修正する必要がないバグがありますが、それらは新機能の開発を遅らせるほど重要ではありません。ただし、システムはこのバグの発生を制御して、それが小さいことを確認する必要があります。これは、自分の直感を信頼できないためです。

これは最初から間違った質問をしていると思います。

問題は「このバグを修正すべきか、このバグを修正すべきではないか」ではありません。開発者は時間に限りがあります。したがって、質問は「1時間、4時間、または1週間で何ができるのか」です。

そのバグを修正することが最も有用なことである場合、ほとんどの人にとってソフトウェアが最大量改善されるため、バグを修正します。他の場所で大幅な改善を行うことができる場合、人々が見逃している機能を追加するか、より重要なバグを修正することにより、これらの他のことを行います。また、将来の開発をより効率的にするためのボーナスポイントが追加されます。

バグ修正は常にやり過ぎです

最初にバグの部分を分類しましょう。

それは正直な間違い、例えば、1回限りのエラーなのか、テストを逃れた変数のシャドーイングなのか？この場合、問題を「修正」することに加えて、新しいユニットテストも作成し、近くのコードをリファクタリングする機会を得たことを願っています。後者はすべて有用な作業です。

ただし、実際に設計上の欠陥である場合は、設計を再評価するか、最悪の場合、この機能を無効にしてください。

ですから、ただ修正しようとしないでください。

もちろん、もっと悪いことをすることもできます--- hack-upon-hackの方法論を試すことができます。ビデオループはハッキングです（アーキテクチャが不適切で、既知の破損があります）。ループ制限を追加して、N回の反復（テストしたブラウザー制限を下回った後）でループが終了するようにすることができます。

影響は明らかです。壊れたコードと新しいループ制限の両方をサポートする必要があります。

PSは極端な見解について謝罪します。

PPS用語に関する注意：バグを「修正」することはできません。獣医はおそらくできますが、そこに行かないようにしましょう;-)。問題は解決または「修正」され、バグは削除または回避されます。