次のシナリオを想像してください。

あなた（または他の誰かの）プログラムにバグがあることを検出しました-特定の入力が与えられると、関数は間違った結果を生成します。あなたはコードを調べて、何も悪いことを見つけることができません：この入力を与えられたとき、それはただ動き出すように見えます。

これで、次の2つのいずれかを実行できます。実際の原因が見つかるまでコードをさらに調べるか、またはif、入力がこの特定の入力であるかどうかをチェックするステートメントを追加して、包帯をたたく-ある場合は、期待値を返します。

私にとって、包帯を貼ることはまったく受け入れられないでしょう。コードがこの入力で予期せぬ動作をしている場合、あなたが見逃した他の入力は奇妙に反応しますか？それはまったく修正のようには見えません-あなたはただ敷物の下で問題をシャベルしているだけです。

これを行うことすら考えていないので、教授や本が「包帯」の修正を適用するのは良い考えではないことを何度も思い出させ続けることに驚いています。だからこれは私に不思議に思う：これらの種類の「修正」はどれくらい一般的か？

時間/期限の圧力が理由の1つです。

締め切りが厳しく、上司が首を呼吸している場合（おそらく文字通り！）、これを実行し、「後で戻って修正します」と考えるのは非常に魅力的で、それがあなただけかもしれませんできる。

もちろん、昨日修正する必要がある新しい問題があるため、実際に戻って適切に修正する回数はごくわずかです。

私たちプログラマーがそれを認めたくないのと同じくらい、美しくコード化されたソフトウェアが常に会社や顧客にとってより多くの価値をもたらすとは限りません。これは、災害の状況では二重に当てはまります。たとえば、ソフトウェアは人々のクレジットカードに二重請求します。時には、包帯のように、必要なあらゆる手段で出血を止めて、患者が安定してから実際に根幹の問題を解決した後に戻ることを約束するだけでよい場合があります。

秘trickは、緊急性がいったんなくなると、包帯を真の修正と交換することを優先するように誰かを説得することは本当に難しいことです。特に、最初の問題の背後には常に別の緊急の問題があることを考慮してください。クイックフィックスを超えて問題にとどまることに警戒する必要があります。

時間

私の意見では一番の理由です。問題がコードベースの問題であれば、調査するのにもっと時間がかかるかもしれませんが。多くの場合、私の「包帯」の修正には、CSSまたはUIの調整が含まれます。それらをすばやく処理するために、かなり厄介なインラインCSSとJavaScriptを作成しました。時間があれば、戻って修正することは常にオプションです。

私たちは例外的にそれらを行います。

開発中の修正については、根本原因がわからない限り修正が行われないようにします。しかしながら：

• 例外的に、根本原因の検索には時間がかかりすぎるか停止し始め、厳しい期限があります。
• 根本的な原因を修正するための例外的なコード変更は、戦術的に実行不可能です（変更には時間がかかりすぎ、期限に近づきます）

そのような場合、「包帯」修正を選択します。次に、根本的な原因に対処するために内部欠陥を開きます。はい、多くの場合、これらの内部欠陥は非常に低い優先度で処理されます。

メンテナンスストリームの修正については、根本原因がわからない限り修正が行われないようにします。しかしながら：

• 非常に例外的に、根本原因の検索は停止しますが、
• 例外的に、根本原因の修正が戦術的に実行不可能であることが発生する可能性があります（変更は簡単ではなく、顧客は昨日修正を必要としていました）。

そのような場合は、まず「包帯」の一時的な修正を選択し、顧客が満足したら適切な修正に取り組み、その後のみ欠陥が解決されます。

明確化。

• 特定のバグを考えると、特定の修正が「包帯」であるかどうかを客観的に定義することはかなり困難です。
• そのため、私は次の定義を使用します。専門的にやるよりもエレガントであまり研究されていない方法で欠陥を修正するために。

まず、「包帯」修正の頻度に関して：

• 新しいコード：ほとんどなし。
• 古いコード：
  • それらは通常、包帯のように見えず、すべてのコードレビューを生き延びられるほど十分にエレガントに書かれています（以下の「データ駆動型の緩和」を参照）。
  • また、「見えない包帯」にも注意してください。単にその関数を呼び出さないでください。コードが不足しているため、バグが存在するというヒントもありません。
• 多くの外部依存関係を持つ古いコード：
  • ほぼ一杯です。
  • ほぼ常に古いバージョンの依存関係のために書かれており、依存関係を新しいバージョンに更新する前に依存関係の「リリースノート」を読む人はいません。

第二に、私のアドバイス：

開発チームのソースコードでバグが発生した場合：

• 専門的な方法で修正してください。（それを修正する場合、あなたはそれを所有します。）
• 時間的なプレッシャーにさらされている場合、できる限り最善を尽くします。
  • 修正を受け入れるかどうかを決定するために、エンドユーザーへの潜在的な影響を見てください：バグ自体、および提案された修正。
  • 関連するコードスニペットを（ソースコード管理ツールの履歴情報を使用して）調査し、問題と解決策を十分に理解するまで同僚と話し合ってください（ただし、時間を費やさないでください）。
• 常にバグ追跡システムでバグを追跡してください。

他のチームのソースコードでバグが発生した場合：

• そのチームにバグを修正してもらいます。
• そのバグは、常に他のチームの欠陥追跡システムに報告してください。

バグが別の会社の（または会社のない）製品で発生した場合：

• この場合、ダクトテープの修正（またはデータ駆動型の回避策）がバグを修正する唯一の方法かもしれません。
• それがオープンソースの場合は、とにかく誰かがそれを調べることができるように、そのバグを何らかの（場合によっては公開されている） 欠陥追跡システムに登録してください。

コードベースの時代に大きく依存すると思います。古いコードでは、20年前のCOBOLルーチンは面白くないと書き直しているのは非常に一般的だと思います。本番稼働中の適度に新しいコードでさえ、まだかなり一般的です。

非常に一般的だと思います。

Joel Spolskyのブログ投稿「The Duct Tape Programmer」をご覧ください

私がこれまでに行ったほとんどすべてのプロジェクトでは、期限を守りタスクを完了するために、何らかの種類の包帯やダクトテープを貼らなければならなかったと簡単に言えます。きれいではありませんが、きれいではありませんが、仕事を終わらせてビジネスを継続し、何らかの形でプロジェクトを進めることができます。

アカデミックな世界と、ソフトウェアが時間とビジネス上の制約の下で実際に出荷する必要がある現実の世界との間には違いがあります。

ある意味では、それを敷物の下に置いて、修正を後回しにすることを望んでいます。悲しいことに、あまりにも頻繁に、遅延修正が行われることはなく、このコードは本番環境に組み込まれます。

コンテキストなしで言うのは難しい-あなたの例では、なぜifステートメントを追加するのが正しい修正ではないのですか？それはおそらく、その入力を処理することになっている他のコードブロックがどこかにあるからでしょうか？

包帯の修正が使用される頻度は、コードの複雑さ、コードに最も精通した人が利用できるかどうかなど、多くの事柄に依存します（Craigの20年前のCOBOLルーチンの責任者は数年前に退職した可能性があります） ）および関連するタイムスケール。

締め切りが顔を凝視していると、根本的な原因を修正するのではなく、単に石膏をたたくだけであっても、より安全な修正を求めることがあります。事態を悪化させない限り問題ありませんが、まだ正しくなく、適切に修正する必要があるという事実を追跡することが重要です。

（デバッグにかかる​​時間に関する限り）その種の修正が本当に問題なく、おそらく理想的な場合があります。

メインの実行可能ファイルのある種のモジュールとして機能するはずであるが、実行するためにメインの実行可能ファイルからの情報も必要とする20個のDLLを持っているシナリオを想像してください。

これらのDLLをメインの実行可能ファイルの外部で使用したい場合は、メインの実行可能ファイルからの戻り値を少し変更する必要があります。A.）このコンテキストには存在せず、B。）このコンテキストに存在したくない。

そうは言っても、コードにコンパイラ指令をいくつか入れて、実際の結果を取得するときと結果を混乱させるときに、まったく異なるコードを実行していることを確認することをお勧めします。

if他の誰かの機能の中に置く代わりに、私は{$ifdef}その機能の周りに置きます-そのように誰もそこにあるべきものとそれを混同しません。