コーディング時にバグの数を減らす方法は？
完璧な人は誰もいません。私たちが何をしようとも、時々バグを含むコードを作成します。新しいソフトウェアを作成するときと既存のコードを変更/維持するときの両方で、発生するバグの数を減らすための方法/テクニックは何ですか？
派手なコーディングは避けてください。コードが複雑になるほど、バグが発生する可能性が高くなります。通常、最新のシステムでは、明確に記述されたコードは高速で十分に小さくなります。
利用可能なライブラリを使用します。ユーティリティルーチンを作成するときにバグが発生しないようにする最も簡単な方法は、ユーティリティルーチンを作成しないことです。
より複雑なもののためのいくつかの正式なテクニックを学びます。複雑な条件がある場合は、ペンと紙でそれらを釘付けにします。理想的には、いくつかの証明手法を知っています。コードが正しいことを証明できれば、修正が簡単な大きくて目立たない明らかなバグを除いて、ほとんど常に良いことです。明らかに、これはこれまでのところですが、時には小さいが複雑なことについて正式に推論することもできます。
既存のコードについては、リファクタリングの方法を学習します。動作を変更せずにコードを読みやすくするために、多くの場合は自動ツールを使用して、コードに小さな変更を加える方法を学びます。
急いで何もしないでください。前もって少し時間をかけて物事を正しく行い、何をしたかを確認し、何をしているのかを考えることは、後で大きな成果を上げることができます。
コードを書いたら、あなたが持っているものを使ってそれを良いものにしてください。ユニットテストは素晴らしいです。多くの場合、事前にテストを作成できます。これは素晴らしいフィードバックになる場合があります（一貫して行われている場合、これはテスト駆動開発です）。警告オプションを指定してコンパイルし、警告に注意してください。
他の誰かにコードを見てもらいます。正式なコードレビューは良いですが、都合のよい時間ではないかもしれません。プルリクエスト、またはscmがそれらをサポートしていない場合は同様に、非同期のレビューを許可します。バディチェックは、あまり正式なレビューではありません。ペアプログラミングにより、2組の目がすべてを見ます。
ユニットテスト 2回目に表示されるバグの数を減らすことができます。コードにバグを見つけた場合、単体テストを作成すると、それが後で再び発生しないことが確認されます。 （さらに、すべてのケースを考えて、何千ものユニットテストを事前に作成するのが難しい場合があります）
私の主要言語はC++とPythonですが、かなり関数型のプログラミングスタイルを開発しました。すべてのコンテキストを関数（またはメソッド）に渡し、その関数がその仕事を行う必要があり、探している意味のあるデータを返すと、コードがはるかに堅牢になることがわかりました。
暗黙の状態は敵であり、私の経験ではバグの最大の原因です。この状態はグローバル変数またはメンバー変数である可能性がありますが、結果が関数に渡されないものに依存している場合は、問題が発生していると考えられます。明らかに状態を排除することは不可能ですが、それを最小化することはプログラムの信頼性に大きなプラスの影響を与えます。
また、すべてのブランチ（if、for、while 、? :)がバグである可能性があることを同僚に伝えたいと思います。バグの兆候がどうなるかは言えませんが、コードの条件付き動作が少ないほど、実行中のコードカバレッジの一貫性が高まるため、バグがない可能性が高くなります。
数字を考えてみましょう。これらすべてもパフォーマンスにプラスの影響を与えます。勝つ！
両方の単体テストコメントで+1。
それを超えて、コンパイラが提供する最高の警告レベルを設定し、警告がエラーとして扱われることを確認してください。多くの場合、バグはこれらの「誤った」エラーに隠れています。
同様に、コンパイル時に実行される静的分析ツールに投資します（私はこれらを追加レベルのコンパイラ警告と見なしています）。
言及されているものに加えて：
- エラーコードを無視しない-例有効な結果が得られた、ファイルが正常に作成された、などとは思わないでください。いつか何かが起こるからです。
- コードがなんらかの条件を入力せず、したがって「その条件を無視しても安全である」と想定しないでください。
- コードをテストしてから、他の人にテストしてもらいます。私は自分のコードをテストするのが最悪の人だと思います。
- 少し休憩してから、コードをもう一度読んで、「明白なものを逃した」かどうかを確認してください。私によく起こります。
今は忘れがちなことは他にもたくさんありますが、他の人はきっとそう思うでしょう。 :)
- より多くのことを行う少ないコードを記述します。
- 低レベルの影響と高レベルの影響について考える
- コードで作成する抽象化を検討してください。
- 可能であれば、本質的な複雑さだけを記述します。
もう少し技術的な答えはありません：疲れている（1日9時間で十分）、酔っている、または「焼けている」ときにプログラムしないでください。疲れているときは、クリーンなコードを書くのに必要な忍耐力がありません。
単体テストおよび統合テストと記述します。
単体テストとツールに関するいくつかの素晴らしい答えがあります。私がそれらに追加できる唯一のものはこれです：
できるだけ早くテスターを関与させる
テストチームがある場合、それらをコード品質のゲートキーパーとして扱い、欠陥をキャッチするという罠に陥らないでください。代わりに、彼らと協力して、できるだけ早く彼らに関与してください（アジャイルプロジェクトでは、これはプロジェクトの最初から行われますが、実際に試してみれば、いつでも彼らに早く関与する方法を見つけることができます）。
- 彼らのテスト計画が何であるかを調べてください。それらを使用してテストケースを確認します。それらすべてをコードでカバーしていますか？
- 要件の理解を求めます。それはあなたのものと同じですか？
- 彼らに探索的テストを行うための初期の作業ビルドを提供します-彼らが提案する改善に驚かれることでしょう。
テスターと良好な関係を築いていると、テスターが何らかのダメージを与える前に、悪い仮定や欠陥を本当に早い段階で見つけることができます。また、テスト担当者は、製品設計を支援し、ユーザビリティの問題を修正する時間があるときにそれを把握する力があると感じます。
静的分析ツール
FindBugs のようなプラグインとアプリは、コードをクロールして、バグがある場所を見つけますpotentialバグ。変数が初期化および使用されていない場所、または10回のうち9回のクレイジーなことで、バグが発生しやすくなります。このようなツールは、たとえバグではない場合でも、骨頭が道を下るのを防ぐのに役立ちます。
PS：常に調査することを忘れないでくださいwhyツールは何かが悪いことを教えてくれます。学ぶことは決して痛くない（そしてすべてがすべての状況で正しいというわけではない）。
コード検査またはペアプログラミングなどのピアレビューの他の形式。
Fagan検査などの構造化されたコードレビュー 少なくとも効果的かつ効率的である可能性があります 単体テストと同等であり、場合によっては単体テストよりも優れていることさえ証明されています。インスペクションは、ソフトウェアライフサイクルの早い段階で、コード以外のアーティファクトとともに使用することもできます。
Karl Wiegersによるソフトウェアのピアレビュー は、このテーマに関するすばらしい本です。
ここでの他のすべての提案に加えて、すべての可能な警告を最高レベルの感度でオンにするとし、それらをエラーとして扱います。また、その言語にあるリンティングツールを使用します。
あなたはamazedで警告によって捕捉できる単純な誤りの数と、それらの単純なもののいくつがコードの実際のバグに変換されるかについて理解します。
ここではたくさんの良い答えがありますが、いくつか追加したかったことがあります。要件を実際に理解していることを確認してください。ユーザーが要件をXと見なし、プログラマーがYを意味するものとユーザーが思ったとき、多くのバグを目にしました。私たちは全員、コードを書き始めたいと思っていますが、理解を確実にするために前もって費やす時間が長いほど、やり直しやバグ修正が少なくなります。
あなたがサポートしているビジネスを知るようにしてください、あなたはしばしば欠けている、またはそれ以上の説明が必要な要件の事柄を見るでしょう。前述のようにタスクYを実行すると、既存の機能Zが無効になることを理解してください。
データベース構造を理解します。多くのバグは、構文的には正しいが間違った結果を返すクエリの結果として発生します。結果がおかしく見えるときを認識する方法を学びます。複雑なレポートクエリを作成している場合、準備ができているとマークする前に、常に技術スペシャリストに結果をレビューしてもらいます。欠落したデータに必然的に何かが表示されます。次に、彼らがあなたがしなかったことをキャッチしたものを自分にメモし、次にあなたが似たようなことをするときを思い出してください。
私は、Code-test-code-testではなくTest-Code-Testの実践に従います。これは、ユースケースを考え、適切にロジックを構成するのに役立ちます
驚いたことに、次の3つの非常に重要なポイントはまだ言及されていません。
アサーションを自由に使用してください。常に自分自身に尋ねる必要がある質問は、「これをアサートする必要がありますか？」ではありません。しかし、「私が主張するのを忘れたものはありますか？」
不変性を選択します。（final/readonlyを自由に使用します。）変更可能な状態が少ないほど、問題が発生する可能性が少なくなります。
時期尚早に最適化しないでください。多くのプログラマーは、パフォーマンスの問題に悩まされ、パフォーマンスが問題になるかどうかを事前に知らなくても、コードを不必要に畳み込み、設計を粗雑にしています。まず、パフォーマンスを無視して、ソフトウェア製品を学術的な方法で構築します。次に、パフォーマンスが悪いかどうかを確認します。 （おそらく問題はありません。）パフォーマンスの問題がある場合は、コードベース全体を調整してハッキングするのではなく、製品がパフォーマンス要件を満たすようにするニースで正式なアルゴリズム最適化を提供できる場所を1つまたは2つ探します。あちこちでクロックサイクルを絞ります。
ReSharper のようなcode inspection toolsまたは IntelliJ IDEA のような多くのコピーについて警告するIDEを使用します-バグなどを貼り付ける「書き込まれるが読み取られない」変数を指摘する。多くの時間を節約してくれました。
最も重要なテクニックは時間をかけてだと思います。新しいモジュールをコーディングするのに2日間は必要だと感じたが、上司に1日だけでコーディングするように強制した場合...コードはよりバグが多いと思われます。
私が少し前に読んだ本の1つは、あなたがbroken windowsと一緒に暮らしてはいけないと言った、他の誰かが壊れても気にならないから...コーディングは同じで、誰もが気になる何かを最初にやる悪いが速いだが、どれも気にしない地獄のコードで、多くのバグがあり、デザインとスタイルが非常に悪い。