完璧な人はいませんし、私たちが何をしようとも、時々バグを含むコードを作成します。新しいソフトウェアの作成時と既存のコードの変更/保守時の両方で、発生するバグの数を減らすためのいくつかの方法/手法は何ですか？
回答:
派手なコーディングは避けてください。コードが複雑になるほど、バグが発生する可能性が高くなります。通常、現代のシステムでは、明確に記述されたコードは高速で十分に小さくなります。
利用可能なライブラリを使用します。ユーティリティルーチンを記述するバグを持たない最も簡単な方法は、それを記述しないことです。
より複雑なもののためのいくつかの正式なテクニックを学びます。複雑な条件がある場合は、ペンと紙でそれらを釘付けにします。理想的には、いくつかの証明技術を知ってください。コードが正しいことを証明できれば、修正するのが簡単で、大きくて愚かで明白なバグを除いて、ほとんど常に良いことです。明らかに、これはこれまでのところに過ぎませんが、時には小さいながら複雑なものについて正式に推論することができます。
既存のコードについては、リファクタリングの方法を学びます。多くの場合、自動化ツールを使用して、動作を変更せずにコードを読みやすくする、コードに小さな変更を加える方法を学びます。
急ぎすぎないでください。少し時間をかけて正しいことをして、自分のやったことを確認し、自分のやっていることを考えると、後で大きな成果を上げることができます。
コードを作成したら、それを使用して適切なコードを作成します。単体テストは素晴らしいです。多くの場合、事前にテストを書くことができます。これは素晴らしいフィードバックになる可能性があります（一貫して行われる場合、これはテスト駆動開発です）。警告オプションを使用してコンパイルし、警告に注意してください。
他の人にコードを見てもらう。正式なコードレビューは良いのですが、都合の良いタイミングではないかもしれません。プルリクエスト、またはscmがそれらをサポートしていない場合は、非同期のレビューを許可する同様のリクエスト。バディチェックは、あまり形式的なレビューではありません。ペアプログラミングにより、2組の目ですべてを確認できます。
単体テストを使用すると、2回目に現れるバグの数を減らすことができます。コードにバグが見つかった場合、単体テストを作成すると、後でバグが再発しないことを確認できます。（さらに、すべてのケースを考え、何千ものユニットテストを前もって書くことは時々やることが難しいです）
言及されていることに加えて：
私が現時点で忘れている他の多くのことですが、他の人は確かにそれらについて考えるでしょう。:)
私の主要言語はC ++とPythonですが、かなり機能的なプログラミングスタイルを開発しました。すべてのコンテキストを関数（またはメソッド）に渡して、その関数が処理を行う必要がある関数（またはメソッド）を返し、探している意味のあるデータを返すと、コードがより堅牢になりました。
暗黙の状態は敵であり、私の経験ではバグの一番の原因です。この状態はグローバル変数またはメンバー変数の場合がありますが、結果が関数に渡されない何かに依存している場合は、トラブルを求めています。明らかに、状態を排除することは実行可能ではありませんが、それを最小化するとプログラムの信頼性に大きなプラスの効果があります。
また、すべてのブランチ（もし、for、while 、? :)がバグである可能性があることを同僚に伝えたいです。バグの発現がどうなるか言うことはできませんが、コードの条件付き動作が少ないほど、実行中のコードカバレッジがより一貫しているという事実だけでバグが発生する可能性が高くなります。
図を見てください。これらのことはすべて、パフォーマンスにもプラスの効果があります。勝つ！
ここで、単体テストとツールに関するいくつかの素晴らしい回答。追加できるのはこれだけです。
できるだけ早くテスターを参加させる
テストチームがある場合、コード品質のゲートキーパーとしてそれらを扱い、あなたの欠陥をキャッチするというtrapに陥らないでください。代わりに、できるだけ早くそれらと協力し、それらを関与させます（アジャイルプロジェクトでは、これはプロジェクトの最初から行われますが、実際に試してみると、いつでも早期に関与させる方法を見つけることができます）。
テスターと良好な関係を築くということは、彼らが損害を与える前に、本当に早い段階で、貧弱な仮定や欠陥をキャッチできることを意味します。また、テスターは、製品設計を支援し、それらを修正する時間があるときにユーザビリティの問題をキャッチする権限を与えられていると感じることも意味します。
コード検査またはペアプログラミングなどの他の形式のピアレビュー。
Fagan検査などの構造化コードレビューは、少なくとも単体テストと同じくらい効果的かつ効率的であり、場合によっては単体テストよりも優れていることさえ証明されています。検査は、ソフトウェアライフサイクルの初期段階で、コード以外のアーティファクトでも使用できます。
Karl WiegersによるPeer Reviews in Softwareは、このテーマに関するすばらしい本です。
ここには多くの良い答えがありますが、いくつか追加したいことがあります。要件を実際に理解していることを確認してください。ユーザーが要件はXを意味し、プログラマーはそれがYを意味すると思ったときに多くのバグを見てきました。貧弱または曖昧な要件についての明確化を押し戻します。私たちは皆、飛び込んでコーディングするのが好きであることを知っていますが、理解を確保するために前もって時間を費やすほど、手戻りとバグ修正は少なくなります。
サポートしているビジネスを知ると、要件に欠けているものや詳細な説明が必要なものがよく表示されます。前述のようにタスクYを実行すると、既存の機能Zが破損することに注意してください。
データベース構造を理解します。多くのバグは、構文的には正しいが間違った結果を返すクエリの結果です。結果がおかしく見えるときを認識する方法を学びます。複雑なレポートクエリを作成している場合、いつでも準備ができているとマークする前に、技術専門家に結果を確認してもらいます。次に、彼らがキャッチしなかったことを自分自身にメモし、次に似たようなことをするときに覚えておいてください。
使用コード検査ツールのようなReSharperのなどのIDE のIntelliJ IDEA「に書かれていますが、読まれることはありません」という変数を指摘等により、多くのコピー＆ペーストのバグなどについて警告。時間を大幅に節約できました。
驚くべきことに、次の3つの非常に重要な点はまだ言及されていません。
アサーションを多用します。あなたが常に自問すべき質問は、「これを主張すべきか？」ではありません。しかし、「断言するのを忘れたものはありますか？」
不変性を選択します。（最終/読み取り専用を自由に使用してください。）可変状態が少ないほど、問題が発生する可能性が少なくなります。
時期尚早に最適化しないでください。多くのプログラマーは、パフォーマンスの問題を傍観しているため、パフォーマンスが問題になるかどうかを事前に知ることなく、コードを不必要に畳み込み、設計を粗悪化します。最初に、パフォーマンスを無視してアカデミックな方法でソフトウェア製品を構築します。次に、パフォーマンスが低いかどうかを確認します。（おそらくそうはなりません。）パフォーマンスの問題がある場合は、コードベース全体を微調整してハッキングするのではなく、製品がパフォーマンス要件を満たすようにすてきで正式なアルゴリズム最適化を提供できる1つか2つの場所を見つけてください。あちこちでクロックサイクルを絞ります。