プログラミング中にコードを実行してテストする頻度はどれくらいですか？
特に、Cでゼロから新しいコードを書くとき、たまに構文チェック以外の目的でコンパイラーを実行せずに、何時間、何日もコードを書いていることに気づきました。
私はより大きなコードのチャンクを注意深く書き、徹底的にテストする傾向があります。それは、コードが頭の流れを分析することで本来の機能を果たすと確信している場合のみです。誤解しないでください。テストなしでは1000行は記述しません（ギャンブルになるでしょう）が、サブルーチン全体を記述してテストし（必要に応じて修正します）、完了したと思った後です。
反対に、エディタに入力するすべての行の後にコードを実行およびテストし、デバッガを注意と正気の代わりに使用できると考える初心者がほとんどです。言語構文を学んだら、これは多くの注意散漫になると思います。
2つのアプローチの適切なバランスは何だと思いますか？もちろん、最初のものはより多くの経験を必要としますが、生産性にプラスまたはマイナスの影響を与えますか？ 2つ目は、エラーをより詳細なレベルで特定するのに役立ちますか？
それは本当にあなたが取り組んでいるプロジェクトの側面に依存します。
OpenGL（ステートマシンのように機能する）で何かをするときは、常にコンパイルして実行し、誤って何かをめちゃくちゃにしないようにしています。関数の最後にリセットすることを忘れずに1つの値を設定すると、アプリケーションで黒い画面のみが簡単にレンダリングされます。
より大規模な「内部」開発では、できる限り多くのテストを事前に取得するようにしています。テストで問題が発生したことが簡単にわかるので、通常は長いコンパイルを待たずにしばらく待つことができます。
UXデザインでは、ある種のビジュアルデザイナを使用します。ビジュアルデザイナは、常に実行される方法（またはそれに近い方法）に見えます。基本的には常に設計コードをコンパイルしています。
個人的には、生物学的L1キャッシュに何時間ものコーディングを保持するほど賢くはないので、小さな塊で作業しなければなりません。機能が限られているため、非常に疎結合になるように小さくてまとまりのある方法を記述し、オブジェクトを設計します。より強力なツールと言語を使用すると、ビルドせずに長くコーディングすることが容易になりますが、それでも私には限界があります。
私の好みは、小さな作品を書くことです。期待どおりに機能することを確認してください。それから、理論的には、その部分の詳細を忘れて、可能な限りブラックボックスとして扱うことができます。
テストを書きたいbefore実装コードを書きます。これが好きな理由は3つあります。
- 事前にテストコードを書くことは、コードの使用方法を考えるのに役立ちます。これは、最初にプログラムを設計したときに思いもよらなかったEdgeのケースを考えるのに役立ちます。
- すべてのテストケースに合格すると、実装コードの作成が完了します。
- コードの前にテストを作成する習慣をつけると、コードに新しいバグが追加されていないことを証明できるという効果もあります（適切なテストケースを作成した場合）。
私は、たまに構文チェック以外の目的でコンパイラを実行せずに、何時間も、何日もコードを書いていることに気づきました。
数時間から数日-これは、コードをより小さなチャンクに分割して、独自に検証およびテストできる機能を見逃していることを示す明らかな兆候です。あなたは間違いなくそれに取り組むべきです。
私はより大きなコードのチャンクを注意深く書き、徹底的にテストする傾向があります。それは、コードが頭の流れを分析することで本来の機能を果たすと確信している場合のみです。
頭の中で分析するのに数時間を必要とする、より大きく、したがって複雑なコードのチャンクを書く代わりに、それほど大きくないビルディングブロックを作成するようにしてください。これはビルドと呼ばれますabstractions-これは優れたプログラミングの要点であり、間違いなく初心者であることの兆候ではありません。
優れたプログラミングは、優れたビラードの演奏のようなものです。優れたプレーヤーはハードストロークを演奏しません。代わりに、彼は各ストロークの後にボールが次のストロークが再び簡単になる位置で停止するような方法でプレーします。そして、プログラマは彼が複雑なコードを書くことができるので良くありません-彼は彼が複雑なコードを書くことを避けることができるので良いです。
次のいずれかの条件が満たされているかどうかをコンパイルしてテストします。
- 最後のコンパイルは15分前でした
- 最後のコンパイルは25行前でした
- 新しい関数/サブルーチンが実装されました
- 大きな変化
- 新機能（または機能として偽装されたバグ）
- バグ修正（「機能」を削除）
- 私は退屈です
コードを実行してテストする頻度は、その時点で使用している言語によって異なります。ストアドプロシージャをコーディングしている場合、通常はすべてが揃うまで待機します。
一方、LISPでコーディングしている場合は、入力した後に各関数を試します。
Haskellでコーディングしている場合は、通常、各関数の後にコンパイルを行って型エラーをキャッチし、すべての処理が完了した後にコードを実行します。
テストを成功させるのに十分なだけのコードを書きます。つまり、数分ごとにテストを実行します。それが私のC++スタイルです。ただし、Rubyでは自動テストを使用しているため、[保存]をクリックするたびに、Niceポップアップを介してテストのフィードバックが返されます。コードの記述を停止することすらせず、バックグラウンドで実行されます。
必要かどうかにかかわらず、1時間に3回。
私たちはテストファーストのプログラミングを行い、動作するコードのみをVCSにコミットします。 smolderbotは20分ごとにレポをチェックアウトし、テストスイートを実行します。失敗した場合は、すぐに修正するためにプログラミングチーム全体にすぐにメールで送信されます。
私にとっては、どれだけ書くかではありません。何千行もの単純なコードをテストすることなく書くことができます。しかし、もっと難しいコードを書いているときは、それらのまとまりのあるセットを書いた後で、各関数を個別にテストする傾向があります。
ただし、コードを実行していることを確認することは、動機づけの大きな後押しになる場合があります。
私のために ;-
短いタイムライン（考える時間はあまりありません）-コードを記述し、コンパイルし、テストします。デバッグ
十分な時間-while（done）{小さなコードを記述、コンパイル}、テスト、デバッグ
それぞれのコーディング概念をテストします。これは関数またはクラスの場合もあれば、ifステートメントにすぎない場合もあります。コンセプトが機能したら、次のコンセプトに進みます。
コードの前にテストを書いてみます。コミットの前にテストを少なくとも2回実行します。その後、Continous Integrationサーバーで再び実行されます。