作業中にコードをコンパイルすることには利点がありますか？

最近、就職の面接を受けました。実際のコードを書くのに1時間かかりました。それほど多くはなく、おそらく100行未満でした。約45分後、コンパイルして実行し、動作するようになりました。コンパイルエラーと2、3の小さなバグを解決するのに5〜10分かかったかもしれませんが、全体的に非常にスムーズでした。（ちなみに、私は彼らから申し出を受けました。）

しかし、私が戸惑ったのは、完成したコードを渡した後、インタビュアーが私が間違ったことは「進行中にコンパイルしない」ことだけだと言ったということでした。私は彼に違いは何であるかを尋ね、彼は「もしあなたがコードを完成させ、それが時間内にコンパイルしなかったらどうするだろう」と言った。

私の理解では、それは無効な引数です。なぜなら、特定の長さのコードに対して「コードをコンパイルする」には、通常、一定数のコンパイルエラーの修正が含まれ、かなり一定の時間がかかります。コードの記述を終了するか、コーディング時間をインターリーブする場合。どちらかといえば、欠落しているセミコロンを検索するためにコーディングを中断することは、おそらくあなたの効率に有害です。派生クラスの仮想関数などのエッジケースの周りの不明瞭さを実験している極端な状況を除いて、経験豊富な開発者によって書かれたコードは、時折の入力エラーを除いてコンパイルされることを期待するのが妥当と思われますそうでない場合、それは '

別の同様の事件では、インタビューで不完全なコードベースが与えられ、それを完成させ、それを実行するために必要な変更を加えるように頼まれました。最初に既存のコードを読んでから、数分後（コードを見終える前であっても）、インタビュアーはそれで十分だと言った。私が彼に何をしたか（すなわち、「私は何を間違えたのか」）と尋ねたとき、彼はすぐにコードをコンパイルすることから始めたと言った。

なぜそれが関連するのでしょうか？私の意見と私の経験では、コードの一部がコンパイルされるかどうかは本質的にランダムであり、セミコロンが欠落しているかどうかなどが含まれており、基礎となるプログラムの正確性とはほとんど関係ありません。（私にとって、コンパイルに焦点を当てることは、文法をチェックするために校正せずに記事をスペルチェックに通すようなものです。）

不完全なコードを教えてくれた場合、最初にすべきことはそれを読むことです。コードが何をしているのかがわかり、アルゴリズムが正しいことがわかるまで、コンパイルしようとはしません。

とにかく、これらは最近のいくつかの事件に過ぎませんが、一般的に、多くの開発者がコードの進行について話をしているのを聞いたことがあります。あなたがコードをテストする利点を理解していますが、なぜコンパイルするのですか？

だから私の質問はこれです：私が逃したものはありますか？実際にコンパイルする利点はありますか？または、これはソフトウェアコミュニティによって伝播された神話のようなもので、コードを頻繁にコンパイルする必要がありますか？

実際にコンパイルする利点はありますか？

がある。これにより、フィードバックループが短くなります。一般に、設計（UI、ソフトウェアの作成、ビジュアルデザインなど）が良いことです。

短いフィードバックループを使用すると、エラーの修正がより高価になる前に、エラーを早期にすばやく修正できます。

あなたの例を借りるには、Cライクな言語でコーディングしていて}、プログラムの途中でどこかを忘れたとしましょう。

ステートメントを書き終えた直後にコンパイルする場合、コンパイルエラーを導入したばかりで、そこで数秒以内に修正できます。

ただし、そうでない場合}は、修正が実際に意図されたものであるというエラーを見つけたら、コードを読んで正確な位置を探し、確認するのに十分な時間を費やす必要があります。これは、そのコードの一部を残してからしばらくすると起こります。あなたが書いた瞬間ほど明確ではありません。

今、はい、最終結果は同じですが、コンパイラがあなたを助けるためにそこにある構文上の問題にかなりの時間を浪費しました-あなたが行っているようにコンパイルした場合、大幅に短縮できる時間。

コンパイルは、特にHaskellやMLなどの型を広範囲に使用する言語でのテストの形式です。他の言語では、ほとんど意味がない構文スキャンです。

そうは言っても、「あなたが行くようにコンパイルする」というのは非常に状況的な習慣のようです。同様に、面接官の個人的な偏見よりも頻繁にコンパイルすることで「けいれん的」であると評価されることもあります。ちょっとしたピッキングのようですね。インタビュイーがテストに合格したことを認めるのを好む人はいません。給与交渉の規模を決めるものです。

すべてのビルドシステムが高速というわけではありません。Makeがビルドに必要かどうかを判断するためにすべてをstatするだけで30秒費やし、変更を加えた場合、ほとんどのファイルはビルドに数分かかる（C ++）プロジェクトに取り組みました。10〜15分ごとよりも頻繁にこれを行うことに消極的でした。誰かが間違いなくパンチカードのデッキを別の建物に運ぶというコンパイルの逸話を提供するでしょう...

頭の中で完全な概念単位を実行し、それを検証する準備ができたと感じたらコンパイルします。ワークフローに応じて、1分に1回または週に1回。

だから私の質問はこれです：私が逃したものはありますか？

はい：あなたの心はコンパイラではありません。コンパイラーは1秒あたりn個のコンテキスト切り替えを行うことができますが、あなたの心はできません。1日に思いつくことができるコンテキストスイッチの数は、コードベースの経験/知識、コードにどれだけ精神的に浸っているか、コードがどれだけきれいか、取り組む問題の複雑さなどの多くの要因に依存します。頻繁に中断されたり、騒がしい環境にいる場合など、あなたがどれだけ疲れているか。

コードベースをコンパイルする（すべて同時に）、初めて（「20ファイルのプロジェクト」を考える）、考えているものからコンテキストを切り替えることを強制します（たとえば、「この値は5に設定されてから、 forループblablabla、および複雑なアルゴリズムは、戻り時に正しい値を生成します」）、あなたが考えているもの（完全に異なるファイル/モジュール/関数/前提条件/構文/変数名、前提条件など）とはまったく関係のないコンパイル問題）。

一度にコンパイルするコードが多いほど、より多くのコンテキストを切り替える必要があります。これは小さなコードベースでは問題になりません。1時間以内に記述したコードがすべて記述されている場合です。ただし、既存のコードベースで作業する場合、相互に依存する複数の（多くの場合文書化されていない）大きな問題です。

実際にコンパイルする利点はありますか？

頭の中で行わなければならないコンテキストの切り替えを最小限に抑え、変更の影響と副作用にもっと集中できるようにします。また、疲れにくく（ミスも少なく）なり、出力の品質が向上します（つまり、10個のファイルをコンパイルして変更するときよりも、一度に1つのファイルを変更してコンパイルするときの副作用を最小限に抑えることができます）。

非常に短い反復でコンパイルする場合（これは、コンパイルプロセスが短時間で最適化されることを前提としています）、「ゾーン」から抜け出すことなくコンパイルエラーを修正することが可能です。

または、これはソフトウェアコミュニティによって伝播された神話のようなもので、コードを頻繁にコンパイルする必要がありますか？

ソフトウェアコミュニティによっても伝播されますが、その背後には正当な理由があります。

私の理解では、これは無効な引数です。なぜなら、特定の長さのコードに対して「コードをコンパイルする」には、通常、一定数のコンパイルエラーの修正が含まれ、かなり一定の時間がかかるためです。

中規模から大規模のレガシーコードベース（数百または数千のソースファイル）の保守に関して、ほとんど（まったく）経験がないように思えます。これは、この態度（つまり、「あなたが行くようにコンパイルする」）が最も役立つ場所であり、このような習慣を形成する場所です。

あなたの意見を聞いた人たちも同様の結論を下したと思います（「大規模なコードベースの経験がほとんどない、またはまったくない」）。

ここには、ちょっとした専門的な索があります。その意味は、「定期的にコンパイルする必要がなかったなら、複雑なものを扱ったことは一度もなかったということです。私たちのやり方とまったく同じように働くことを学んだら、さらに経験を積んで戻ってきてください。」

しかし、明らかにこれには別の側面があります。一部のプロジェクトはコンパイルに時間がかかります。わずかな編集を行ってもコンパイルに30分以上かかるフレームワークを使用しました。ヘッダーファイルを編集する必要がある場合は、Heavenが役立ちます。通常、完全な再コンパイルは一晩で行われます。コンパイラを使用してミスを検出している場合、部分的なビルド中に検出されないまれなエラーがまだあります。これらの条件下では、5分ごとに再コンパイルする必要はありません- 怠feelingな気分でない限り。

コンパイラは論理エラーまたはセマンティックエラーを解決することはできません。構文エラーは、コンパイルに1日の半分を費やす価値があることを回避するのが難しくありません。もちろん、時折タイプミスをすることもありますが、タッチ入力と読み取りの両方ができると仮定します。自由に選択できる場合は、レイアウトをうまく活用するコーディングスタイルを使用して、エラーを視覚的に強調表示し、ブレース、ブラケット、またはセミコロンを再びドロップしないようにします。それは少し練習し、ほとんどが慣れているよりも少し規律がかかりますが、それは可能です。プレーンテキストエディターで一度に2、3時間コードを記述し、10回中9回以上初めてコンパイルできます。確かに、もっと頻繁にコンパイルすることはできましたが、結果として修正しやすいエラーが最後にあったことを思い出せません。

あなたが絶え間ない再コンパイルのファンでないなら、あなたは良い仲間です。ドナルド・クヌースは次のとおりです。

あなたの本当の質問に関しては、完全に未知の環境で自分のやり方を感じており、何が機能し、何が機能しないかについてのフィードバックが必要な場合、即時コンパイルと「ユニットテスト」のアイデアは私にほとんど訴えません。そうしないと、実行する必要も考えもする必要のないアクティビティに多くの時間が無駄になります。

すべてのことは...言われているならば、あなたはコンパイルがなぜないだろう、フリー・アクションであるコンテキスト内で作業していますか？自宅では、個人的なプロジェクトで、コンパイラのフロントエンドを介してコードを常に実行してリアルタイムのエラーを強調表示するIDEで、ほぼ30秒に1回ctrl-Sと「コンパイル」ショートカットを押します。なぜ無料のランチを渡すのですか？

コンパイルすることにはメリットがあります。しかし、私は仕事にとどまることがOKのコーディング戦略であることに非常に同意します。

インクリメンタルコンパイルの最も重要な利点は、コンパイルとテストが終了するのを待つ場合に多くの人が参加するという考え方です。最終的には、その時点でコードを実行することに関心があります。この構文エラーが隠れている根本的なセマンティックエラーがあるかどうかを考えずに、「ああ、コンパイラが文句を言うのをやめるためにこのブラケットを追加するだけでいい」または「これを大文字にするだけでいい」と言います。私は本当に構文エラーがセマンティックエラーにしばしばネストすることを発見します（逆は真実ではありません）。

例として、変数の意味を変更し、その結果、名前を変更したとしましょう。名前の変更により、後のコードで構文エラーが生成されますが、名前を修正してコンパイラーを喜ばせただけであれば、そのエラーが発生した理由を無視しました。

あなたがコードをテストする利点を理解していますが、なぜコンパイルするのですか？

しかし、それに応じてコンパイルしない場合、どのようにコードをテストしますか？

極端な場合は、テスト駆動開発（TDD）です。TDDは、書き込みテスト、コンパイル（失敗）、書き込みコード、再コンパイル、実行テスト、修正バグ、再コンパイル、リファクタリング、コンパイルの非常に短いサイクルを意味するため、TDDが戦略で機能しないことは明らかです。 -もう一度、実行テスト、そして...

だから、誰もがTDDをしているわけではなく、少なくとも常にそうではありません（私も認めます）。現在の戦略では、TDDを試すことさえできません。しかし、TDDを実行していない場合でも、コードをより定期的にテストすることは非常に役立ちます。定期的にコンパイルしないと不可能です。また、テストが失敗すると、デバッグを実行します（数分前に作成した見栄えの良いアルゴリズムが、思ったほどうまく動作しない理由を理解するのに役立ちます）。そして、コンパイルせずに書くコードが多いほど、テストせずに書くコードが増えるため、問題を修正する時間が「O（1）」であると予測できない場合に遭遇する可能性が高くなります。あなたが書いた。

経験豊富な開発者にとって、コンパイラーのエラーは大した問題ではないはずだということに実際に同意します。それらを修正するためのコストは、時間をかけて心配するほど大幅に増加するとは思わない。プッシュの直前まですべてのコンパイラエラーの修正を延期することができた場合、はるかに小さく、より統合された中断が発生するため、私はそうします。

残念ながら、コンパイラが行うことはコンパイラエラーの検出だけではありません。明白なことを述べるリスクはありますが、プログラムを実行するにはコンパイルが必要であり、経験豊富な開発者でさえ作成する、より複雑で微妙で興味深いランタイムバグを見つけるには、プログラムの実行が必要です。そして、これらのタイプのバグはより困難であり、したがって、デバッグを延期するほど修正がより高価になります。

ただし、インタビューの演習で、コンパイルを最後まで延期するために、必ずしも誰かをマークダウンするわけではありません。面接の練習は非常に簡単である傾向があり、経験豊富な開発者は通常、自分の限界を知っています。自分が書いたものについて自信があるほど、コンパイル間を長くすることになります。それはただの人間性です。

ただし、それを評価しないためには、自信を正当化する必要があります。あなたがコンパイルせずに何かを書くのに45分を費やし、それをデバッグするのにさらに45分を必要としたなら、私はあなたに対してそれを重く考えていただろう。

私が見る限り、他の回答から欠落していることが多い、しばしばコンパイルに関する重要なことは、これです：めったにコンパイルせずに大量のコンパイラエラーが発生した場合、それらのほとんどは最初のエラーによって生成されるため、無意味です。タイプ、タイプミス、または宣言を無効にする単純な構文エラーが原因である可能性があります。

常に最初のものを修正し、再コンパイルし、次の残りのものを修正することなどができますが、コードベースが大きい場合、これは遅くなる可能性があります。しかし、コンパイラエラーの長いリストと独立したエラーを特定しようとすると、無関係なメッセージを読んだり、二次的なエラースポットから実際の原因までコードをナビゲートしたりするのに多くの時間を費やします。

通常のビルドでは、コードの完全なブロックが作成されてすぐにコンパイルが開始されると、すぐにコンパイルが開始されます。コンパイルが終了するまで新しい編集内容を保存しない限り、コンパイルの進行中にさらにコードを書き続けることができます。そのため、ビルドを待つ時間はほとんどありません。その時点で書こうとしていることをすべて書き終えるまで待つ場合、何もせずにコンパイルを待つ必要があります。これは基本的に、最新のIDEがバックグラウンドで自動的に実行できることの手動バージョンです。

経験豊富なプログラマーにとって、コードのコンパイルがボトルネックになることはありません。

言語を十分に理解したら（つまり、構文について考える必要がなくなり、代わりに機能のためのコードだけを作成するとき）、単純な構文エラーを作成しない傾向があります。作成するのは通常、タイプミスまたはコピーペーストのバグであり、わずかなコンパイルパスで短時間でクリーンアップできます。

私はコンパイルせずに終日定期的にコードを書いてから、コンパイルして、コードをコミットする前にコンパイラーが報告する構文エラーと警告を修正します（「テストが必要です！」と書かれています）。わずか数分で1,000行以上のCまたはC ++コードをクリーンアップできます。

一方、デバッグとテストには時間がかかります。あらゆる種類の理由で論理エラーが発生しますが、書くのを完全に忘れたサブルーチンについて教えてくれるコンパイラーに会ったことがありません。またはnode->left、あるべき時に貼り付けたためにバイナリー・ツリーが機能しないことに気付きますnode->right。

インタビュアーと戦うのは一般的に賢明ではないと思いますが、自分のスタイルを守る価値があると感じたら、書いたコードをデバッグするのに十分な時間を残したことを指摘しておかなければならないと思います。それは、優れたプログラマーが決して無視しないことです。

ps-コードを読んでコードをレビューするのを見ていたら、その場であなたを雇っていただろう。それは、プロが毎回行うことです。

いいえ、十分な量のコードを実行するまでコンパイルを延期するのは不合理ではありません（「十分な量」はコーダーと書き込まれているコードによって異なります）。

たとえば、あなたがそれを正しくするのに時間をかける素晴らしいコーダーであり、大量のコードや複雑なコードを書いていない場合、定期的にコンパイルすることは無駄であり、おそらく気が散ることもあります。そうでない場合は、すべての関数をコンパイルすることをお勧めします。それは人次第です。

反例として、JavaScriptコードを書いていると想像してください-コンパイラはありません。代わりに（ほとんどのJavaScriptコードの性質を考慮して）プログラムを実行（またはページを更新）して、コーディングの結果を確認します。今、あなたは理にかなった十分なコードを書かれるまでそれをすることができません。その結果、JavaScript開発者はできる限り頻繁に「コンパイル」する傾向がありますが、これは必ずしも頻繁ではありません。

要するに、ここには正しい答えはありません-インタビュアーは間違っていませんが、あなたもそうではありません。生産性を高めるものを実行し、誰かがあなたにすべきだと言っていることを忘れてください。コーディングには、F7定期的にヒットする（またはヒットしない）傾向がまったく影響しないことよりもはるかに重要な要素があります。

優れた開発環境では、実際にコードをテストする予定がない限り、コンパイルする理由はほとんどありません。バックグラウンドの構文チェックツールは、インタビュアーが話していると思われるほとんどすべてをキャッチしますが、常に完全に特定されているわけではない（ファイル全体に伝搬する変更を含む）いくつかのケースがあることは認めます。

そうは言っても、実際に結果を生成できるコードの最小単位をほとんどコンパイルして実行しようとします。30分前、私はいくつかの検索結果を印刷する手段を作成していましたが、結果をより良く見えるようにするために、10数回のコンパイルの速度で（紙ではなく.pdfに）半ダースのテスト印刷を行いました行。

私の意見と私の経験では、コードの一部がコンパイルされるかどうかは本質的にランダムであり、セミコロンが欠落しているかどうかなどが含まれており、基礎となるプログラムの正確性とはほとんど関係ありません。（私にとって、コンパイルに焦点を当てることは、文法をチェックするために校正せずに記事をスペルチェックに通すようなものです。）

私の経験は非常に異なります：私が得るコンパイルエラーの5％未満は構文に関するものです。私は言語をよく知っています。エラーが発生した場合、ほとんどは型エラーであり、セマンティクスが正しくないことを教えてくれます。

これが、コンパイラーのフィードバックから可能な限り迅速に利益を得られることを嬉しく思う理由です。コンパイルエラーをリアルタイムで強調するIDEの使用を経験したことがありますか？フィードバックループを短くすることは非常に有益です。

不完全なコードを教えてくれた場合、最初にすべきことはそれを読むことです。コードが何をしているのかがわかり、アルゴリズムが正しいことがわかるまで、コンパイルしようとはしません。

他の人が書いたコードで作業することが予想される場合、すべてを読む時間があるとは限りません。良いニュースは、うまく書かれたコードは結合度が低く、必要なコードの部分だけを独立して推論できるようにする必要があることです。

そのような場合、まだ読んでいないコードが正しいと仮定し、問題がある場合は遅延調査する必要があります。

一定のコード長の「コンパイルするコードを取得する」には、通常、一定数のコンパイルエラーの修正が含まれ、かなり一定の時間がかかります。コーディング時間と一緒に。

コンテキストの切り替えは脳にとってコストがかかるため、小さなエラーを修正したらすぐに修正する方が効率的です。

編集：チーム全体が同じソースで作業している場合、ソース管理との類似性を確認することもできます。コンパイルは、頻繁にコミットを行うようなもので、すべてをマージして整理する必要があるときに、最後に多くの苦痛を避けるのに役立ちます。

あなたはあなたのテキストの下に赤い線のようなものを無効にするという。メールを入力したり、技術文書を書いたりするときにもそうしますか？次に、間違いを修正する代わりに、すべてのページを再度校正する必要があります。

もう1つの利点は、コードの作業中に、常にコンパイルまたはほぼコンパイルを続けると、多くのセマンティックベースのIDE機能（安全な名前の変更、リファクタリング、シンボルの使用の検索など）を活用できることです。 。

これらの機能がどのように役立つかをより深く理解したい場合は、それらを有効にして練習し、自分自身の利点を体験してみてください。また、慣れ親しんでいる人とペアプログラミングを行って、それらの利点を確認することもできます。

インタビュアーに何か非常に悪いことがあると感じ、それが何であるかを正確に指摘できなかったので、これについてもう少し考えました。ここに問題があります。過去20年間に書いたコードの場合、実行可能なアルゴリズムをコンパイルするコードに変えるのに必要な時間は最小限でした。その領域での効率の向上は、開発時間全体にほとんど影響を与えないため、まったく無視できるものであり、その領域で非効率であると思われる候補者を拒否するインタビュアーは、優れた開発者になる理由を知りません。

ほとんどの時間は、コードが行うべき情報の収集、使用する必要のある外部サービスに関する情報と仕様の収集、コードをハッキングする代わりに正確で保守可能なコードにつながるグローバル設計の作成、およびアルゴリズムの検索に費やすべきです。それは、動作するまで一緒にパッチが適用されるコードではなく、動作するコードにつながります（明らかにエラーのないコードと明らかなエラーのないコード）。

その後、コンパイルするコードを書くために少し時間がかかります。

その後、コードが機能することを確認し、コードが機能し、機能し続けることを確認するために、より多くの時間が費やされます。これは、最初に適切に設計されたコードを使用することにより、ユニットテストを作成し、コードをステップ実行し、大部分を実行することによって行われます。

このインタビュアーは、私の返信で10語でカバーされていることに集中しました。これは、実際の作業時間の10％以下を表します。そして、その開発者が信頼できる実用的なコードを作成する能力にほとんど影響を与えません。

「順を追ってコンパイルする」ことの利点は、一定のフィードバックが得られることであり、正しい方向に進む前に大した間違いをする可能性はありません。あなたのような有能なプログラマーにとって、それは大きな考慮事項ではありませんが、他の多くの人にとってはそうです。別の言い方をすれば、「場合に応じてコンパイルする」ことは、場合によっては潜在的な効率の損失がありますが、「最大損失を最小化する」方法です。

最近の企業は、完成品に興味があるだけではありません。彼らはそれがずっと「制御下にあった」ことを知りたいと思っています。彼らにとって、「そこに着くのは半分の楽しみです。」

ここでの他の回答は、仕事で頻繁にコンパイルするための良い防御策を講じていますが、あなたの質問はインタビューに集中しているので、その角度に取り組みたいと思います。

私のインタビューでは、正反対のことをします。候補者はコンパイラを使用できません。彼らはホワイトボードに短いプログラムを書いてから議論します。コンパイラー（またはインタープリター）を松葉杖として使用している開発者が多すぎることを発見しました。私があなたにたくさんのお金を提供していて、コンパイラなしでFizzBu​​zzを正しく書くことさえできないなら、あなたはおもちゃの運動よりも100倍難しい問題に取り組んで、長期的にそれを切ることは決してないでしょうインタビューで。それでも、これらの簡単な演習は、インタビューの他のどの部分よりも多くの候補者を除外しました。

面接の目的は、候補者とビジネスの相互適合性を評価することです。適切なインタビューの質問には、質問の目的とインタビュー対象者の評価方法を明記する必要があります。インタビュイーにトリックの質問を投げかけ、隠された答えを知らないとペナルティを課しても、インタビュアーまたはインタビュイーは役に立たない。残念ながら、ほとんどのプログラマー（上級者でも）は、他のプログラマーと面接する訓練を受けていないため、決まり文句に頼って、面接時に尋ねたのと同じタイプの質問をします。か否か。

私のアプローチが「真の方法」であると主張しているわけではありませんが、非常にうまく機能しています。大文字で始まる多くのソフトウェア方法論と同様に、面接には同じ数の「義務」があります。彼らはすべて二段です。あなたとあなたのビジネスのために働くことをする必要があります。

いくつかのサブルーチンを使用する大規模なプロジェクトでは、特定の部分が既に機能していることがわかっているとデバッグが簡単になるため、これらの部分をより大きなスキームで使用する前にテストする必要があります。

これらの小さい部分をテストするには、コンパイルする必要があります。

インタビュアーがこの状況を、この方法で設計されていない小さなプログラムと混同している可能性があります。

2回目のインタビューに関して、コンパイルの利点は、プログラムが実行する（または実行しない）ことをほんの数秒で確認できることです。そこから、コードを読み、関連する部分に努力を集中するのが簡単になります。おそらく、これはインタビュアーが期待していたことです。

このような未知のコードベースを最初から最後まで読むことは非常に非生産的です（あなたはコンパイラではありません）が、アプリケーションをコンパイル/実行するとすぐに全体像がわかります。