「エンジン」は 1.3 ではなく、現在は 170 万行のコードであると述べているパネル ディスカッションを聞いています。それは私を怖がらせます。その行数やモジュールの量などを想像することはできません.C++は他の言語ほどモジュールを処理できないといつも感じていました。大規模なプロジェクトは管理が難しく、コード行を合理的に抑えることが好ましいと感じました。10kラインを打つと違和感があります。20k、50k、500k、または 100 万がどのように感じられるか想像できません。
この規模のプロジェクトを開発および維持する際に、どのような慣例がありますか?
100 万行のコードは、ほとんどの人間がすべてを頭に入れておくことができるポイントを超えています。つまり、チーム メンバーはそれぞれ、システムの不完全なメンタル マップを持ち歩くことになり、設計に関する議論が困難になる可能性があります。
複数の不完全な理解を軽減するには、適切な一連のアーキテクチャ図の形でマップが必要です。これらには通常、システムのアーキテクチャの非常に高レベルのブロック図が含まれ、重要な部分のより詳細な下位レベルの図と、適切な詳細レベルで重要な相互作用を説明するためのシーケンス図が含まれる場合があります。このような図を手の届くところに置くことで、システムについて話し合うときにチームが「同じページにいる」ことができます。
「サブシステム間の依存関係」ダイアグラムは、クリーンアップする必要がある混乱した領域 (「うーん? 永続化フレームワークのそのビットが UI に依存するのはなぜ?!?」 タイプ) を指摘することもできます。これらの図の生成を自動化する方法を見つけられれば最高です。Graphviz はあなたの友達になることができます。
この規模のプロジェクトを開発および維持する際に、どのような慣例がありますか?
分割して征服するため、このサイズのモノリシックなプロジェクトはありません。
この規模のプロジェクトを開発および維持する際に、どのような慣例がありますか?
それが、開発者からアーキテクトへと進化するときです。
大規模なソフトウェア プロジェクトでは、プロジェクト リーダーの関心は実装ではなく構造レベルで絞り込む必要があります。コンポーネント/ライブラリを適切かつ正しくモジュール化し、適切に分離し、設計パターンを利用します。
私にとっては行数ではなく、設計がどの程度モジュール化されているか、モジュールがどれだけうまくカプセル化されているかです。ある時点から、いわばモジュールにズームインし、その設計が何であるかを把握し、機能を記述してバグを修正できれば、コードの行数は問題になりません。間違いなく、100 万行を超えるコードのシステムに取り組んだことはありません。
この規模のプロジェクトを開発および維持する際に、どのような慣行がありますか？
大規模なソフトウェアプロジェクトを管理するための多くの考え方があり、明らかにそれはプロジェクトのタイプに大きく依存します。
資金提供されたソフトウェア開発は、通常、最初から正式なプロセスを使用する傾向があります。「趣味の」プロジェクトでは、必要なプラクティスのみを採用して、表示されるペイントポイントに対処する傾向があります。
他の人から指摘されているように、その規模のプロジェクトは必然的にチームの努力であり、直面する多くの課題は、活動を調整し、混乱を制限する必要性から生じます。
しかし、それらはすべて、複雑さを処理するために同じ「戦術的」手法を使用する傾向があります。Joel Testのこの紹介を読んで、いくつかの有用な/必要なプラクティスを理解することをお勧めします。
それはどのようなタイプのエンジンですか？ゲーム エンジンであれば、グラフィック、サウンド、物理、マップ処理、およびその他の数十のモジュールに確実にモジュール化されています。すべてのモジュールには必ずいくつかのサブモジュールが含まれています。つまり、グラフィックスはフォント レンダリング、エフェクト、GPU 固有の部分などに分割されます。
依存していると思います。下手なシェフに良いシェフと同じ量の食材（つまり、たくさん）を与えることができます。
私はプロジェクトを行数で考えているのではなく、(ご指摘の通り) プロジェクト自体の保守性で考えています。プロジェクトがモジュール化され、適切にリファクタリングされている限り、それほど悪くはないかもしれません。
したがって、あなたの質問に答えるために、大規模なコード ベースを維持するために使用するプラクティスは、任意のサイズのコード ベースを維持する場合と同じです。自動ビルドを高いコード カバレッジ (できればシステム レベルのテスト) と統合することを検討します。読みやすく (checkstyle など)、重複しないコード (simian など) などを作成するのに役立つツール。
プロジェクトが成長し続け、行数が多くなり、コード ベースが適切に開発された場合、それはクライアントが満足し、より多くの機能を求めていることを意味するだけだと思います。