構築に非常に時間がかかる場合、エンジニアの効率を改善するにはどうすればよいですか？
プロジェクトはC++を使用しており、コードは32コアボックスでビルドするのに約30分かかります。その時間は長くなる可能性があります。開発者のローカルマシンで1時間以上。
ビルドをしていると効率が悪いことに気づきました。ただ座ってそれを見るのは時間の無駄です。
典型的なケースは、コードを変更してからビルドし、ビルドが失敗した場合は再度変更し、ビルドしてテストし、テストが失敗した場合は変更して再度ビルドします。
コードはテンプレートでいっぱいなので、.Hでの変更はビルドに長い時間がかかります。
1人の開発者がビルドプロセスで毎日2時間を浪費する場合、コストは高すぎます。
現在のコードベースがビルドに長い時間を必要とするプロジェクトを処理するときに効率を向上させる方法は？
1つは、テンプレートにどれだけ依存しているかを再評価することです。典型的なC++プロジェクトでは、独自のテンプレートを作成することは比較的まれです。
次に、依存関係ファイルを生成していることを確認して、実際にインクリメンタルビルドを実行できるようにします。これは、多くのツールチェーンで驚くほど簡単に間違ってしまうことがあります。
次に、プリコンパイル済みヘッダーを調べます。
それを除けば、主なことはビルド全体を毎回コンパイルしないことです。通常、一度に1つのファイルで作業します。完全なビルドシステムの外に一時的にコピーする必要がある場合でも、その1つのファイルをコンパイルしてください。依存関係のスタブを作成し、ユニットテストを実行するためのファイルを作成します。迅速なコンパイルサイクルで、その1つのファイルを分離して作業し、統合テストの準備ができたら、それをメインビルドにコピーして戻します。
もう1つは、フルビルドにできるだけ多くのテスト機能を組み込むことです。 2つのアルゴリズムを決定する必要がある場合は、両方の方法で記述し、ランタイム構成を使用してアルゴリズムを選択する方法を作成します。バグの原因を探そうとしている場合は、大量のロギングを使用してビルドを作成します。デバッガを使用して、実行時に小さな変更を加える方法を学びます。
もう1つは、2つのタスクを同時に処理することです。最初のタスクがコンパイルされている間に、他に取り上げることができます。
適切なインクリメンタルビルドの作成をすでに提案している他の回答への追加：
- distcc などを使用して、分散ビルドの機会を探ります。
- ヘッダーを小さな部分に分割し、一部のインターフェイスを変更しても、同じヘッダーファイル内の無関係なものを使用する関数が再コンパイルされないようにする
- 可能な場合は常に前方宣言を使用します。たとえば、関数またはメソッド
Foo getFoo(Bar bar)がある場合、実際にgetFoo(...)を呼び出さない限り、FooまたはBarを実装する必要はありません。 STLテンプレートを転送宣言できないことに注意してください。 - テンプレートの使用を実装に制限し、インターフェースで使用しないでください
- pimpls を使用します
- 機能ブランチ用にビルドするCIがある
- 開発者をリセットして履歴に戻さないでください。マスターを1回フェッチしてビルドし、開発中に段階的にビルドします。専用の worktree を使用して機能ブランチにチェリーピックし、プッシュせずにマスターで新しい機能を開始します。 CIは、同期が取れていないために起こりそうにないコンパイル失敗のイベントを通知します。
- プロトタイピング中に、ダーティトリックを使用して、使用頻度の高いヘッダーファイルに触れないようにします。安全でないキャスト、グローバル変数、定義をインプリメントファイルにインクルードする代わりにコピーします。もちろん、実装が決まったら、これを正しく行う必要があります
PS：
典型的なケースは次のとおりです。コードを変更してからビルドし、ビルドが失敗した場合は再度変更し、ビルドしてテストし、テストが失敗した場合は変更して再度ビルドします。
コードはテンプレートでいっぱいなので、.Hでの変更はビルドに長い時間がかかります。
ヘッダーのテンプレート変更のエラーを見つけるためにプロジェクト全体を再構築する必要はありません。プロジェクト内の1つまたは複数のファイルだけをコンパイルするように要求できるはずです。それらが成功した場合は、おそらくヘッダーが正しいはずです。
コードベースをモジュールに分割します。変更が影響を与える場合にのみ、それらを再構築します。ヘッダーを関連する関数の小さなグループに分割して、未使用の関数がほとんど含まれないようにします。
安定したヘッダーが重要です。大規模なプログラムに投入する前に、十分にテストしてください。
真剣に、これが私たちがそもそもモジュールを発明した理由です。変更されたものだけを再コンパイルし、リンカに残りを接続させます。
あなたのボトルネックが実際に何であるかを調べてください。それは、CPUがあなたを支えているものではない可能性があります。
言語/フレームワーク/プラットフォームに関係なく、遅いフィードバックループは非効率につながります。人々はコンテキストからコンテキストへのジャンプやその日の1分ごとの活用が本当に得意ではないため、管理者はこのプロジェクトのビルド時間のコストを理解する必要があり、開発者は1日6回の変更を試す必要がある20分以上、15分のビルド。
これが実現され、より高速なフィードバックループが優先されると、それがどのように達成されるかについて他のいくつかの回答を見てください。代わりに開発者がいくつかの新機能を優先するように言われている場合、それはそれ自体がサイドプロジェクトとして起こることはありません。