プログラミング中にコードを実行およびテストする頻度はどれくらいですか？[閉まっている]

特に、Cでゼロから新しいコードを書くとき、たまに構文チェック以外のコンパイラを実行せずに、何時間も、何日もコードを書くことに気づきます。

私は、大量のコードを慎重に記述し、頭の中でフローを分析することでコードが本来行うべきことを確信している場合にのみ徹底的にテストする傾向があります。誤解しないでください-テストせずに1000行を書くことはありません（ギャンブルになります）が、サブルーチン全体を書いて、終了したと思ったらテストします（必要に応じて修正します）。

反対側では、エディターに入力するすべての行の後にコードを実行およびテストし、デバッガーが注意と正気の代わりになる可能性があると考えている初心者がほとんどです。言語の構文を学んだ後は、これは多くの注意散漫になると思います。

2つのアプローチの適切なバランスは何だと思いますか？もちろん、最初のものはより多くの経験を必要としますが、生産性にプラスまたはマイナスの影響を及ぼしますか？2つ目は、より細かいレベルでエラーを見つけるのに役立ちますか？

それは本当にあなたが取り組んでいるプロジェクトの側面に依存します。

• OpenGL（ステートマシンのように動作します）で何かをするときは、常にコンパイルして実行し、誤って何かを台無しにしないようにします。関数の最後で値をリセットすることを忘れずに1つの値を設定すると、アプリケーションが簡単に黒い画面のみをレンダリングする可能性があります。

• 大規模な「ボンネットの下」での開発では、できるだけ多くのテストを事前に取得しようとしています。テストにより、何が壊れたかをより簡単に知ることができるので、通常の長いコンパイルを待つことなくしばらく行くことができます。

• UXデザインの場合、私は何らかのビジュアルデザイナーを使用します。これは常に実行される（またはそれに近い）ように見えます。基本的には常に設計コードをコンパイルしています。

個人的には、生物学的なL1キャッシュに数時間のコーディングを保持するほど頭が良くないため、小さな塊で作業する必要があります。私の能力は限られているため、小さく凝集したメソッドを作成し、オブジェクトを非常に疎結合に設計します。より強力なツールと言語を使用すると、ビルドせずに長くコーディングすることが容易になりますが、私にはまだ制限があります。

私の好みは、小さな作品を書いて、期待通りに機能することを確認することです。それから、理論的には、私はその作品の詳細を忘れて、可能な限りブラックボックスとして扱います。

実装コードを書く前にテストを書くのが好きです。私は3つの理由でこれが好きです：

1. 事前にテストコードを書くことで、コードの使用方法を考えるのに役立ちます。もともと自分のプログラムを設計していたときに思いもしなかったエッジケースを考えるのに役立ちます。
2. すべてのテストケースに合格すると、実装コードの記述が終了したことがわかります。
3. コードの前にテストを書く習慣を身に付けることは、コードに新しいバグが追加されていないことを証明できるという追加の効果もあります（良いテストケースを書いたと仮定）。

コンパイラーを実行することなく、時折構文チェックを行うことなく、何時間も、何日もコードを書くことに気づきました。

数時間から数日-これは、コードを小さなチャンクに分解する能力を見逃しているという明確な兆候であり、それを独自に検証およびテストできます。あなたは間違いなくそれに取り組むべきです。

私は、大量のコードを慎重に記述し、頭の中でフローを分析することでコードが本来行うべきことを確信している場合にのみ徹底的にテストする傾向があります。

頭の中で分析するのに何時間もかかる大きなコードの塊を書く代わりに、複雑なコードの塊を書く代わりに、それほど大きなものではなく、小さな構成要素を作成してみるべきです。これは、抽象化の構築と呼ばれます-それが優れたプログラミングの要点であり、間違いなく初心者を狙う兆候ではありません。

優れたプログラミングは、優れたビラード演奏に似ています-優れたプレーヤーはハードストロークを演奏しません。その代わりに、彼は、各ストロークの後にボールが次のストロークが再び簡単になる位置で停止する方法でプレーします。そして、プログラマーは複雑なコードを書くことができるので良くありません-彼は複雑なコードを書くことを避けることができるので良いです。

次の条件のいずれかが満たされている場合、コンパイルとテストを行います。

• 最後のコンパイルは15分前でした
• 最終コンパイルは25行前でした
• 新しい関数/サブルーチンが実装されました
• 大きな変化
• 新機能（または機能を装ったバグ）
• バグ修正（「機能」を削除）
• 私は退屈です

コードを実行してテストする頻度は、その時点で使用している言語によって異なります。ストアドプロシージャをコーディングしている場合、通常はすべてが完了するまで待機します。

一方、Lispでコーディングしている場合は、入力後に各関数を試します。

Haskellでコーディングしている場合は、通常、各関数の後にコンパイルを実行して型エラーをキャッチし、すべてが完了した後にコードを実行します。

テストをグリーンにするには、十分なコードを記述します。つまり、数分ごとにテストを実行します。それが私のC ++スタイルです。ただし、Rubyでは自動テストを使用しているため、保存するたびに、素敵なポップアップを使用してテストのフィードバックを取得します。コードを書くのをやめることさえしません。それはバックグラウンドで行われます。

必要かどうかにかかわらず、1時間に3回。

テストファーストプログラミングを実行し、作業コードのみをVCSにコミットします。smolderbotは20分ごとにレポをチェックアウトし、テストスイートを実行します。障害は、すぐに修正するためにプログラミングチーム全体にすぐに送信されます。

私にとって、それは私がどれだけ書くかではありません。テストせずに数千行の簡単なコードを書くことができます。しかし、私がより難しいコードを書いているとき、それらのまとまりのあるセットを書いた後、私は各関数を個別にテストする傾向があります。

ただし、コードを実行しているのを見ると、しばらくの間何も実行していない場合に、動機付けが大幅に向上します。

私にとって;-
短いタイムライン（考える時間はあまりありません）-コードの記述、コンパイル、テスト。
十分な時間のデバッグ-while（done）{小さなコードを書いて、コンパイル}、テスト、デバッグ

各コーディングコンセプトについてテストします。これは関数またはクラスである場合もあれば、ifステートメントにすぎない場合もあります。コンセプトが機能したら、次のコンセプトに進みます。

コードの前にテストを書きます。コミットの前に少なくとも2回テストを実行します。その後、Continous Integrationサーバーで再度実行されます。