たとえば、Autodesk Mayaの規模と複雑さのコード、2千万から3千万行以上のコードについて話しています。

必要に応じて開発をフリーズした場合、単一のバグがなくなるまで、すべてのバグを実際に修正できますか？バグのないシステムの存在に対する賛否両論は何ですか？

修正するたびにバグが増えるという考えがあるため、それは真実ではないと思います。

バグとは、UIの最も単純なタイプミスから、回避策のないより深刻な予防バグまでを意味します。たとえば、特定のスクリプト関数は法線を正しく計算しません。また、回避策がある場合でも、問題を解決する必要があります。したがって、提供された関数を使用する代わりに、この特定のことを手動で行うことができますが、その関数はまだ修正する必要があります。

Mikeyが述べたように、バグのないコードを書くことは目標ではありません。それがあなたが目指しているものである場合、私はあなたのためにいくつかの非常に悪いニュースがあります。

重要な点は、ソフトウェアの複雑さを非常に過小評価しているということです。

まず最初に-プログラムの実行方法の全体像を無視しています。完全なシステム上で単独で実行されるわけではありません。最も基本的な「Hello World」プログラムでさえオペレーティングシステム上で実行されるため、最も単純なプログラムでさえ、オペレーティングシステムに存在するバグの影響を受けやすくなっています。

ライブラリの存在により、これはより複雑になります。オペレーティングシステムはかなり安定している傾向がありますが、ライブラリは安定性に関してはさまざまな問題を抱えています。いくつかは素晴らしいです。その他...それほどではない...コードに100％バグがないようにしたい場合は、実行するすべてのライブラリが完全にバグがないことを確認する必要がありますが、多くの場合、これは不可能ですソースコードがない場合があります。

次に、考えるスレッドがあります。ほとんどの大規模なプログラムは、至る所でスレッドを使用しています。競合状態やデッドロックが発生しないように注意してスレッドを記述しようとしますが、コードのあらゆる組み合わせをテストすることは不可能です。これを効果的にテストするには、CPUを通過するコマンドのすべての可能な順序を調べる必要があります。これについてはまだ計算していませんが、チェスの可能なゲームをすべて列挙する方が簡単だと思います。

機械自体を見ると、物事は困難から不可能になります。CPUは完璧ではありません。RAMは完璧ではありません。ハードドライブは完璧ではありません。マシン内のコンポーネントはどれも完璧になるようには設計されていません。それらは「十分に」設計されています。完全なプログラムでさえ、マシンの一時停止のために最終的に失敗します。それを止めるためにできることは何もありません。

結論：「バグフリーソフトウェア」を書くことができますか？

番号

そうでなければあなたに言う人は誰も無知です。

理解して保守しやすいソフトウェアを作成してください。それができたら、1日と呼ぶことができます。

編集：一部の人々は、私が完全に見落としていたすばらしい点についてコメントしました：コンパイラ。

アセンブリで記述している場合を除き、コンパイラがコードを台無しにする可能性は完全にあります（コードが「完璧」であることを証明しても）。

一般的に使用されるコンパイラの1つであるGCCのバグのリスト：http : //gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=c%2B%2B&resolution=---

数学的にMIGHTあなたが「バグ」を定義する方法に応じて、このような複雑の「buglessのソフトウェアを書くことが可能。MIGHTであることを証明することも、あらゆるコードをあらゆる可能な方法、あらゆる可能なユースケースで実行するテストシステムを設計することにより、数学的に可能です。しかし、私は確信していません-複雑な計算を行うシステムを扱っている場合、「無限の問題」に遭遇する可能性があります...

実際には、あなたが話しているサイズと範囲のシステムでは、これは不可能です。このような「バグのない」システムを作成し、指数関数的に時間がかかることを証明するシステムを作成するには、1000年かかる場合があります。 1つ-そして、妥当な時間に似たもので話しているサイズと範囲のシステムのすべてのユースケースを実際にカバーしたと判断する方法はないと思います。

IMOのあなたの質問は少し間違っています。開発者としての私たちの目標は、「バグのない」ソフトウェアを書くことではありません。私たちの目標は、使いやすく、柔軟性があり、メンテナンスしやすいソフトウェアを作成することです。

使用可能：システムは、設計された重要な要件を満たしています。バグがあるかもしれません-しかし、それらは「エッジケース」にあります-外れ値、または迷惑であり、システムの基本を損なうバグではありません-堅牢です。

保守可能：バグは簡単に分離および修正でき、新しいバグを作成しないでください。

柔軟性：システムは、大幅な再設計やダウンタイムなしで簡単に変更および拡張できます。ほとんどの変更では、既に適切に設計されたパターンとフレームワークに適合する新しいクラスまたはモジュールを追加するだけです。

優れた設計慣行、優れた制御慣行、優れたチームワーク、良心的な開発者-これがGOOD SOFTWAREの公式です。（完璧ではない- 良い）

この記事によると、スペースシャトルのオンボードソフトウェアは非常に近くなりました。420,000行プログラムの最後の3つのバージョンには、それぞれ1つのエラーがありました。このソフトウェアは、260人の男性と女性のグループによって管理されていました。これらの人々の多くは検証者であり、その唯一の目的はエラーを見つけることでした。

シャトルが全地球測位衛星でナビゲートできるようにするソフトウェアのアップグレードは、プログラムのわずか1.5％、つまり6,366行のコードに影響を与えました。その1つの変更の仕様は2,500ページを実行しました。プログラム全体の仕様は30巻を満たし、40,000ページ、つまり仕様のページごとに平均10行のコードを実行しました。

予算は問題ありませんでした-年間35ミリオンで、彼らは正しいことをする余裕がありました。

基本的に、いいえ、とにかく最善を尽くす必要があります。理由を説明します（または十分な忍耐力がない場合は、結論にスキップします）

バイナリ検索の実装と同じくらい些細な問題を考えてください。非常に人気のある実装の1つに、約20年にわたって検出されなかったバグがありました。バグなしで広く使用され、正しいと証明されたと思われるまでに20行が20年かかる場合、巨大なプログラムにバグがないことを本当に期待できますか？

とにかく巨大なプログラムにはいくつのバグがあると予想できますか？私が見つけた1つの数字は「1000行ごとに10個の欠陥」（コード完全版第2版、517ページ-データを引用するのではなく、単に例を使用した）でした。幸いなことに、プログラムの品質を改善する方法があります。ユニットテスト、コードレビュー、および通常の手動テストは、バグの数を減らすことが知られています。それでも、数はまだ多くなります。

すべてのバグの95％を解決できたら、それは信じられないでしょう。それでも、ソフトウェアにはまだ10000〜15,000のバグがあります。

幸いなことに、このソフトウェアは広く使用されている（したがって、広くテストされている）ため、バグが発見されます。そのため、バグは徐々に少なくなります。ただし、バグが少ないということは、残りのバグを見つけるのが難しくなることも意味します。したがって、バグ修正に直線的な曲線を期待しないでください。最後のいくつかのバグを見つけるのは本当に難しいだろうと（彼らはしていると仮定すると、数年のための検出を逃れることができ、これまで見つかりました）。

また、ソフトウェアが変更されなければ、新しいバグは発生しないと誤って想定しているようです。ソフトウェアがサードパーティのライブラリに依存している場合、新しいバージョンはいくつかの機能を破壊する可能性があります-アプリケーションのコードが同じ場合でも新しいバグを導入します。新しいオペレーティングシステムは、以前は完全に動作していたアプリケーションを破壊する可能性もあります（一般的な例については、Windows Vistaを参照してください）。コンパイラのバグなども考慮してください。

コードプルーフツールがバグのあるソフトウェアの問題を本当に解決できるかどうかは不明です。プログラムの停止の問題を解決することは確かに不可能ですが、プログラムが指定どおりに動作することを証明することは可能かもしれません… 証明プログラムにバグがあるのか​​もしれません。仕様自体にバグがあるかもしれません。

明らかに、バグの数を大幅に減らすことができますが、ゼロになることはほとんどありません。

修正するたびにバグが増えるという考えがあるため、それは真実ではないと思います。

（強調を追加）

あなたは正しいです。この記述は間違っています。以下に例を示します。

int main() {
    int x[10];
    x[10] = 8; //Buffer overflow here
    return 0;
}

それでは、このバグを修正しましょう。

int main() {
    int x[11];
    x[10] = 8; //No buffer overflow here
    return 0;
}

見る？バグを修正し、新しいバグを導入しませんでした。

ただし、バグを修正するたびに新しいバグを作成するリスクがあることは確かに正しいですが、このリスクは軽減できます（たとえば、単体テストを使用）。

バグを100個修正するたびに、誤って新しいバグを導入するとします。したがって、10000個のバグを修正すると、100個の新しいバグが発生します。そして、これらの新しいバグを修正すると、1つのバグが発生します。しかし、だから何？このプログラムのバグは9 999個少なくなったため、おそらく以前よりも改善されたと考えられます（新しいバグが以前のバグの10000倍ではないと仮定した場合）。

また、バグを修正すると新しいバグが明らかになる可能性があります。ただし、これらのバグも修正できます。あなたが正しいことをすれば、最終的にはソフトウェアは当初よりも良い状態になります。

私は、OPで言及した概念のために、多くのバグを修正しない方が良いと、いくつかのトッププログラマーによって年をとりました。

この動作は過失です。バグがあり、修正できる場合。やれ。もちろん、新しいものの追加を防ぐために最善を尽くす必要がありますが、修正する10個の重大なバグごとに1つの小さなバグを導入する場合、それはバグの修正を停止する正当な理由ではありません。実際、バグを修正し続けることは正当な理由です。

したがって、修正するバグが少なくなり、将来バグが戻ってくることも少なくなります

修正するバグが少ないほど、ソフトウェアに残るバグが多くなり、ユーザーに迷惑をかけます。確かに、彼らは「将来あなたに戻る」ことはありません。彼らはそもそも去らなかったので、彼らは戻ってきません。「カムバック」の概念は回帰に関連しています。繰り返しますが、回帰のリスクを減らすことが可能です。

一部のバグはあまりにも広く使用されるようになり、人々がそれらに依存し始め、バグを修正するとそれらのユーザーのプログラムが壊れてしまうため、修正できません。それは起こります。ただし、その場合、それらは本当にバグと見なすことができますか？

「バグを修正し、バグを作成する」という考え方は、That Horrible Monsterに関連している可能性があります。コードベースにモンスターがある場合、何かを行う前に、まずモンスターを非モンスター化する必要があるかもしれません。

最後に、あなたがひどいプログラマーである場合、触れたものが新しいバグを作成するリスクがあります。これは明らかに上級プログラマーを緊張させるでしょう。しかし、「何もしないでください。何も触れないでください。息さえしないでください。」おそらく健康的な職場環境を作るための正しい方法ではありません。教育は優れています。

結論：

• たくさんの新機能を取得し続けるが、バグ修正がないソフトウェアは避けられません。
• 適度な数の新機能を取得し、バグを修正したソフトウェアは、使用可能になる可能性が高くなります。
• バグを少なくしようとする人は、気にしない人よりも（平均して）バグが少ない。
• プログラムが最終的にバグフリーになると期待することは合理的ではありません。
• 上級プログラマーは必ずしも有能ではありません。
• バグを修正します。
• ソフトウェアの品質を向上させる方法論を採用します。

バグのないプログラムを作成しない理由は、ほとんど経済的です。

プログラムの正確さを証明する数学的方法があります。高品質のコンピュータサイエンスコースでは、それらに言及します。この目的のために特に開発されたプログラミング言語があります。理論的には、バグのないプログラミングが可能です。

はい、数百万年前に遠い超新星から発射されたニュートリノがたまたま適切な場所でプロセッサにヒットしたため、ビット値を変更する可能性のある不完全なハードウェアがあります。さて、すべての理論には仮定と抽象化があります。しかし、プロセッサがアドバタイズされたとおりに動作すると仮定すると、プログラムも正しく動作することを確認するための数学的なツールがあります。

このトピックで非常に投票された回答の中には誤解を招くものがあります。たとえば、ゲーデルの不完全性定理と停止問題は、プログラムの正確性または不正確性を判断する自動化ツールなどを使用できないことを意味するだけです。しかし、プログラムの正確性を判断するのではなく、特定のプログラムの正確性の証明のみが必要です。

（アナロジー的には、数学定理の真理を自動的に決定するプログラムを書くことができないからといって、特定の数学定理を証明できないという意味ではありません。）

代わりに、問題はこれです：

理論的にはバグのないプログラムを書くことは可能ですが、そうすることは非常に高価です。正しいことを証明するコードを書くのは、壁に何かを投げて、それが固まっているかどうかを確認するよりも複雑です。「固執するかどうかを確認する」が単体テストで行われたとしても、そして多くのプログラマーはそれをすることさえしません。ほとんどのプログラマーは、それを行う方法すら知らないでしょう。つまり、会社としてより高価なものを雇わなければならないということです。

すべてのコストを考慮すると、一般的な顧客は、100パーセントうまく機能する安価なソフトウェアを使用するよりも、99パーセントの時間（および追加の更新プログラムをインストールした後99.9パーセントの時間）で機能する安価なソフトウェアに満足しています時間。また、顧客はこのソフトウェアを10年または20年ではなく今すぐに入手したいと考えています。

したがって、人々はバグが発生する可能性のあるソフトウェアを故意に作成し、バグがあまり頻繁ではなく、あまり深刻ではない最適な組み合わせを見つけようとします。実生活で最大の利益をもたらす組み合わせ。（時には、競合他社が何かをリリースする前にバグでいっぱいのソフトウェアをリリースし、競合他社が最初の適切なバージョンをリリースする準備ができたときにのみ、より適切なバージョン2.0をリリースすることさえ意味します。）

必要に応じて開発を凍結した場合、単一のバグがなくなるまで、すべてのバグを実際に修正できますか？

数学的に言えば、できます。経済的に言えば、なぜ誰もがそうするのでしょうか？それはおそらく20年と数百万ドルを費やすことを意味します。一方、顧客は新しい機能を望んでおり、凍結したアプリケーションはそれらを提供できませんでした。そのため、あなたの完璧なバージョンの準備が整うと、市場はすでに競合他社に奪われています。

経済的に推論しても大丈夫です。私たちはお金と時間が重要な世界に住んでいます。しかし、経済的な理由で何もしないからといって、理論的にもそれができないことについてナンセンスなことを言ってはいけません。誰が知っているか...おそらく数年以内に、正確性の証明を容易にする新しいプログラミング言語とツールがいくつかあるでしょう。

番号。

David Hilbertは、1900年に数学の2番目の問題を提案しました。これは本質的に、算術が意図したとおりに機能することを証明するように世界に求めました。彼は後に「Entscheidungsproblem」を提唱し、論理的な用語で同様のことを尋ねました。 Kurt_Gödelの「最初の不完全性定理」は1931年に初等算術の理論が一貫性と完全性を兼ね備えていないことを証明しました。 アランチューリングの Entscheidungsproblemの「停止問題」としての表現は、問題をこの問題の中心に直接動かし、そこでプログラムが完全に実行されるかどうかを証明することは不可能であることを証明しました。その不確実性を考えると、プログラムにバグがあるかどうかを証明することもできません。

そのどれも、私たちの間で実践しているプログラマーがバグなしに努力することから解放されません。それは単に一般的に成功できないことを意味します。

エラマ

B-methodのような正式な言語でコードを記述しても、要件が満たされていることを数学的に証明するために使用できますが、

正式な仕様言語を使用している場合でも、

ユーザーのニーズを1つ以上の脳からコンピューターに抽出するという人間のステップが常に存在します。

この人間のステップはエラーが発生しやすく、ワームはリンゴの中にあります。

私が遭遇した「バグ」のかなりの割合は、システム設計と顧客の期待との不一致としてより適切に説明されるかもしれません。

現在、これらのバグを呼び出すかどうかは学術的ですが、不完全なコミュニケーションと顧客の期待の変化の直接的な結果として、かなりのメンテナンス作業が発生するという事実は残っています。

システムが技術的に、仕様を満たしているという意味で「正しい」と証明されたとしても（実際の商用ソフトウェアではあり得ないことですが）、ソフトウェアの機能を顧客のこれまでと一致させるという問題がまだあります。変化し、不十分に定義された期待。

要するに：

番号。

仕様が十分に厳しく制限されている場合、バグのないプログラムを証明できる可能性がありますが、それはシステム内の他のすべてが正しく機能するという証明不可能な仮定のみに基づいています。これは、元の問題を提起した人、またはサービスを使用している人が仕様が正しいと見なされることを証明する方法がないことを前提としています。

このトピックについては、ジムショアのセクションNo Bugsが非常に有用であることがわかりました。短い形式：バグを生成せずに開発することはできませんが、バグをできるだけ早く検出できるように作業できます。

コード自体の生成中。たとえば、開発中にユニットテストを頻繁に作成して実行することにより、コードが意図したとおりに動作することを常に保証します。また、意図したシステムの動作を最も明確に表現するように、既存のコードを永続的に書き換えることは便利です。

ただし、あなたのケースでは、数百万行のコードを持つ既存のコードベースについて話している。そのようなシステムのバグを無料で取得したい場合は、まずこのシステムの「バグ」を知る必要があります。システムの機能を保証する一連の事後テストを作成できます（まだ存在しない場合）。これらのテストのウェブは、正しいシステムの振る舞いのおおよその定義として役立つかもしれません。しかし、コードが多くなればなるほど、そのような演習には多くの労力がかかります。そのため、ほとんどの企業は妥協を余儀なくされています。彼らは不完全な状態で生活し、バグリストとメンテナンスを使ってシステムから最も厄介なバグを取り除きます。

コンピューター部分による検証について。

コンピューターを使用してプログラムを検証するには、2つの方法があります。1つはテストで、もう1つは証明システムを使用しています。

徹底的なテストが不可能になるとすぐに、テストにはプログラムにバグがないことを示すことができなくなります。（そして、テスト自体がバグの存在をテストしていないことを示す問題があります）。

証明システムを使用するには、正式な要件から始めます（そして、それら自体にバグがある可能性があります。できれば、要件に使用される言語は、プログラミング言語よりもバグがないことを納得させるのにより適しています）。プログラムにバグがないことの証明システムの助け（そして証明システムにはバグの問題がありますが、それ自体が正しいことを証明しました）。現在の最新技術はCサブセットのコンパイラです（サブセットはアカデミックではなく、「CompCertはCのMISRA-C 2004サブセットのすべてに加えて、MISRAによって除外される多くの機能をサポートします」）。

いいえ。コードが凍結されている間も、アプリケーションが実行されるコンピューターとソフトウェア環境は変化し続けるためです。オペレーティングシステムは、デバイスとドライバーだけでなく、パッチと修正プログラムとともに進化し続けます。既知のバグがなくなったと思われる場合、AMDまたはnVidiaは、ビデオサブシステムとの対話方法に影響を与えるビデオドライバーの更新をリリースします。現在、特定のビデオカードまたは構成（SLI？LOL）を使用している顧客向けに、アプリケーションに視覚的な欠陥（点滅、ちらつき、フレームレートの低下など）があります。

ハードウェアとOSのほかに、最も重要なアプリの下には多くのミドルウェア製品もあり、これらも制御できないほど進化します。コードを欠陥のない状態にすると、その下のレイヤーはEOLになります。

テクノロジーは進化し、テクノロジーを活用するビジネスも進化します。コードを「解放する」という考えは不可能または実現不可能です。新しい機能セットを求めるビジネスは、「既知のバグをすべて追跡している間にコードがロックされており、Xか月以内に有効なソフトウェアの欠陥を報告する人はいない」にうまく対応できません。ビジネスがそのラインを購入したとしても、Xか月後に新しい機能がどのように登場するかを尋ねられます。答えは「Oracleはパッチをリリースするだけで、さらにXか月かかるため、フリーズを延長することにしました」それを証明するために」。

いいえ、ある時点で、ビジネスはテクノロジーのスピードで前進する必要性をサポートする、より柔軟な開発チームを探します。これは、現代の開発チームが直面する根本的な問題です。

はい、しかしあなたは確かに決して知ることはありません。見づらくなればなるほど、あなたはもっと見つけます。システムがより重く使用され、より多くのエッジケースが使用されるほど、元の意図または仕様との別の不一致を見つける可能性が高くなります。これは、バグ自体が正確なものではなく、多くの場合、解釈、特定の異常をどれほど個人が評価するかに依存することを意味します。

あいまいなことです。最後のビットまで指定されているシステムはほとんどありません。システムが正常に機能し、ユーザーが苦情を持たず（何もバグがない）、ユーザーが完全に適応している場合は、バグなしと呼ぶこともできます。

十分な規律とチームの文化を共有することで、バグのないソフトウェアを一貫して提供することが可能です。（そして、適切にモジュール化されたモジュラーコード、自動化されたテストの包括的なスイート、欠陥の検査とプロセスの適応、および労力と謙虚さを必要とするが何千も返す他の多くのこと）

ただし、これを行うと、通常20 MLOCシステムを構築することはありません。バグのないコードを書くことが目標でない場合、どちらも多くのMLOCシステムを構築するべきではありません。

私自身の理由は次のとおりです。

一部の人は満たす必要があります。一部の人（おそらく同じ人、場合によっては別の人）には、ソフトウェアの作成を通じてニーズを満たす予算があります。これらの人々はすべて、自分のお金でいくらかの利益を得ると期待しています。

予算のある人は、プログラマと呼ばれる人（おそらく同じ、場合によっては異なる）に支払います。そのため、これらのプログラマは、合意された時間を、ニーズを満たすソフトウェアに変えます。

したがって、これらのプログラマーは、他人のお金をニーズを満たすソフトウェアに変換することに取り組んでいます。このお金を有効に使うのは彼らの責任です。

これは、質問に関して次のような意味を持ちます。

• ソフトウェアにバグがある場合、それを修正しますか？バグを修正するにはプログラマーが必要です。プログラマーにはお金がかかります。プログラマーはそれをするためにお金を使うかどうかを決めることができません。それは予算を持っている人の役割です。
• 最終的に未修正のバグを残さずに20MLOCソフトウェアをゼロから構築できますか？まあ、20MLOCの構築に着手するには、莫大な金額を費やすつもりでした。これは経済的に愚かです。そして、それは一日で構築されていません。しかし、ソフトウェアは、明日ではなく今日のニーズに対応しています。多くのプログラマーを雇って開発を並列化するという見当違いの試みがあります。しかし、そうなると、共有された文化が得られず、バグが発生し、無駄と遅延が発生し、それらを修正するための資金が不足する可能性があります。このサイズのバグのないシステムはまだ見ていません。（バグのないシステムと20MLOCシステムを見てきましたが、同じではありませんでした）
• 私は書いていない20MLOCシステムの維持を担当しています。既知のバグをゼロにすることはできますか？これはプログラマーに依存しません。彼らはバグを修正することを決定することはできません。なぜならそれは彼らのお金ではないからです。残りのバグを修正するのに十分なROIがありますか？さて、このシステムはしばらく前から存在しており、ユーザーはそれに慣れており、日常業務でシステムの癖を活用しています。原則としてバグを修正する場合、お金を持っている人は、システムから消えた不特定の機能を再開発するためにお金を払わなければならず、さらにお金がかかります。

それはすべてお金に関するものであり、当然です。

はい。

しかし、ご存知のように、その価値を得るには、あまりにも多くの努力が必要です。

答えを守る前に、まずバグとは何かを定義する必要があります。

• バグは、仕様に反する動作です。
• ただし、仕様の不具合（たとえば、ロボット工学の0番目の法則）はソフトウェアのバグとしてカウントされません。
• 仕様で禁止されていない限り、追加機能はバグとしてカウントされません。
• 議論のために、仕様内の矛盾もソフトウェアのバグとしてカウントされません。

既にご存知のとおり、優れたソフトウェアアーキテクチャはモジュール式であるため、各モジュールを個別に単体テスト（または手動テストなど）できます。規律と慎重なテストにより、バグのない個々のモジュールを書くことができます。

"ちょっと待って！" 「あるモジュールの予期しない（それにもかかわらず正しい）動作が別のモジュールのバグを引き起こすとしたらどうでしょう？」次に、バグは2番目のモジュールにあります。バグのないモジュールはAPIとして扱うことができ、APIはご存知のように、正しく使用するには多少の注意が必要です。

防弾コードを書くには、開発者側のエッジケースとフローロジックに関する広範な知識が必要です。ほとんどのソフトウェア開発者は、学習するのに十分なほど賢くないか、単に気にしません。またはより頻繁に、彼らは締め切りにあります。

「しかし、立つ場所を与えてください。そうすれば、世界を動かすでしょう。」- アルキメデス