回答:
AgdaまたはCoqのコード。コードがコンパイルされると、動作します。ハードコアすぎる場合は、HaskellやF＃など、型システムの弱い言語を選択してください。
それでも、ほとんどの場合、20％の時間をコーディングに、80％をテストとデバッグに費やす生産性がはるかに高くなります。1週間の100％は1時間の20％をはるかに超えています。デバッグが物事を成し遂げるために必要なものである場合、デバッグは時間の無駄ではなく、この割合を「改善」することに煩わされるべきではありません。
単体テスト。
単体テストの適用を開始した後、作成したコードの構造が改善されたことがわかりました。その場合、バグを回避して発見するのが簡単になりました。デバッグに費やす時間は減りましたが、単体テストの作成により多くの時間を費やしました。
また、単体テストに費やした時間は、デバッグよりも投資に対する見返りが高いと思います。デバッグセッションの後、コードを修正しました。同じバグが数週間後に現れる可能性があり、再度デバッグする必要があります。単体テストを作成すると、バグは単体テストとして文書化され、後で回帰テストとして機能します。バグが再び表示される場合、ユニットテストはこれを私に明らかにします。
a + bコードの一部でさえ適切に単体テストを行うことはできません（テストが算術データ型の全範囲をカバーしていない限り）。
ユニットテストは、実稼働コードの前にそれらが壊れるバグを導入する場合に役立ちます-よく書かれたユニットテストは、正確に何が壊れたかを教えてくれます。
ほとんどの場合、これで問題は解決しますが、99.999％のプロジェクトでは、時間をかけてデバッグする必要があります。ここで行うのに最適なことは、4つのことを行うことです。
デバッグ時間を短縮する方法は？より少ないコードを記述します。
真剣に、コードを書いている限り、それをデバッグする必要があります。単体テストなどは非常に役立ちますが、その必要性を完全に取り除くとは思わないでください。
ほとんどの答えは、デバッグしなければならない問題の数を減らす方法に焦点を当てているようで、それは価値があります。ただし、デバッグは常に必要であるため、デバッグを高速化する方法を検討すると便利です。
バージョン管理ソフトウェアの使用方法を知ってください。
使用するプログラミング言語の理解を深めてください。
論理的になる
単体テストのコメントに追加しますが、コードがそれをサポートするために分離されている場合（MVCなど）にのみ本当に良いです。MVC（または同様の）（レガシープロジェクト）を実装できない場合、ユニットテストはUIでまったく機能しません。次に、自動化されたUIテスト（Microsoft Coded UI Tests、WaitN）を追加します。これにより、コードのその部分のエラーが減少します。
また、静的分析ツール（MSの世界ではFxCop / Microsoft Code Analysis、Resharper、JustCodeなど）を実行することを強くお勧めします。これらはすべての種類の一般的なコーディングの問題を見つけることができ、愚かなデバッグタスクを削減し、ビジネスロジックのデバッグにより重点を置くことができます。
それを機能させ、それから速くし、そしてきれいにしなさい。ほとんどのバグは、初期の最適化または完全に問題のないコード行のリファクタリングに起因します。オブジェクトの向きを使用する場合、自分自身を繰り返さないでください。特にメソッドが制約で機能する場合は、単純にして、値の範囲の健全性チェックを常に行ってください。ミスを少なくするのには役立ちませんが、バグをより迅速に見つけるのに役立つ可能性が高いため、デバッグにかかる時間は短くなります。
最近、この問題について多くのことを考えてきました。簡単な答えは、Don NormanのThe Design of Everyday Thingsを読んでください。製品を設計するようなコードを書きます。
言い換えれば、優れた設計はエラーを最小限に抑えます。これは、いくつかのことを意味しますが、そのほとんどはすでに行っています（ただし、正確な理由はわからないかもしれませんが）。
-名前は直感的に機能します。これは正式にはアフォーダンスとして知られています。つまり、ボタンを押したり、レバーを切り替えたり、ハンドルを引いたりすることができます。
-悪いコードを書くのを難しくしてください。不正な入力をチェックし、エラーをスローするのではなく、遅らせる、必要に応じてハンガリー語のアプリを使用するなど。これらはロックアウト関数と呼ばれます。
-必要に応じて抽象化を使用します。短期記憶が弱い。
-ドキュメントは明らかに重要ですが、コードが適切に使用されていることを確認するのは最も効果的ではありません。つまり、適切に設計された製品には、ドキュメントは必要ありません。（これを確認する最も明白な方法は、悪い例を見ることです。つまり、押すべきハンドルのあるドアです。）
-ユニットテスト。これらは、バグがどこにあるのかを明らかにするだけでなく、実際にエラーを防ぐものではなく、健全性を提供します。
私はもっと多くの原則を見逃していると確信していますが、ポイントはエラーのための設計について読んでください。
上記の単体テストを完全にサポートしていますが、最初に問題と解決策について考える必要があるため、TDDまたはBDDは非常に価値があります。
しかし個人的には、静かに座って問題とそのアプローチの仕方と各アプローチの長所と短所について考えるために数分かかるだけで、コードの品質に疑問を抱き、混乱を解消するのに役立ちます。
時々、紙の上にすばやく落書きをすると、パズルのより大きな接続部分を見るのに役立ちます。
最初に頭を下げてキーボードをたたくと最悪のコードを書きます。少しの思考と熟考が世界を変えます。
PS。5時間というのは10時間ということで、数時間で大きなスペックを書くのではありません。
私の2つの上位の考えは、1）予期しない何かをすると失敗するより良いコードを書く2）デバッグが上手になる
私のコードは散らかっています
if(value!=null) throw new NotImplementedException();
if(obj.v>0) throw new Exception(); //sometimes i dont write NotImplementedException
if(value=="thing") throw ...;
そのコードを実行するたびに例外がスローされ、デバッガーが停止するため、新しい機能でコードを作成したり、条件を回避したりするのではなく、何が起こっているのか、バグを抱えている
コールスタック、ブレークポイント（条件付き）、イミディエイトウィンドウ（プロンプトウィンドウまたはレプリケートウィンドウとも呼ばれる）、「ウォッチ」変数など、さまざまな問題をデバッグするのに優れています。