それから青信号があり、物事を整理するために、誰かがGameManagerを作成します。おそらくGameStateの束を保持するために、おそらくいくつかのGameObjectを格納するために、実際には大きなものは何もありません。かわいい、小さな、マネージャー。
ご存知のように、これを読んでいると、頭の中で少し警報が鳴りました。「GameManager」という名前のオブジェクトは、決してかわいい、または小さなものにはなりません。そして誰かがこれをしてコードをクリーンアップしましたか？以前はどのように見えましたか？冗談はさておき、クラスの名前はクラスが何をするのかを明確に示すものである必要があり、これは1つのことです（別名：単一責任の原則）。
また、GameManagerのようなオブジェクトで終了する可能性がありますが、明らかに、非常に高いレベルで存在し、高レベルのタスクに関与する必要があります。ゲームオブジェクトのカタログを維持していますか？おそらく。ゲームオブジェクト間のコミュニケーションを促進しますか？承知しました。オブジェクト間の衝突を計算しますか？番号！これが、名前マネージャーが眉をひそめている理由でもあります-それは広すぎて、そのバナーの下で多くの乱用を可能にします。
クラスサイズに関する簡単な経験則：クラスごとに数百行のコードが実行されている場合、何かがおかしくなり始めています。過度に熱心にならずに、たとえば、300 LOCを超えるコードは私にとってコードの匂いです。1000を超える場合は、警告音が鳴ります。どういうわけか、1000行のコードは、それぞれ250の4つの適切に構造化されたクラスよりも理解しやすいと信じることで、自分を欺いていることになります。
時間が問題になると、別のクラスを記述したり、この巨大なマネージャーをサブマネージャーに分割する方法はありません。
これは、すべての問題が完全に混乱するところまで問題が伝播することを許可されているためだと思います。リファクタリングの実践は本当にあなたが探しているものです- あなたは継続的に小さな増分でコードの設計を改善する必要があります。
これを防ぐために何を提案しますか？
問題は技術的なものではないため、技術的な修正を探すべきではありません。問題はこれです。チームにはモノリシックなコードを作成する傾向があり、中長期的にはこのように動作することが何らかの形で有益であるという信念があります。また、ゲームのアーキテクチャを操作する強力なアーキテクチャリードがチームにないようです（少なくとも、この人は忙しすぎてこのタスクを実行できません）。基本的に、唯一の方法は、この考え方が間違っていることをチームメンバーに認識させることです。それは誰も好意しません。製品の品質が低下し、チームはさらに多くの夜を費やして問題を修正します。
幸いなことに、クリーンなコードを作成することの直接的な具体的なメリットは非常に大きいため、ほとんどすべての開発者がそのメリットをすぐに実感します。しばらくこの方法で作業するようにチームを説得し、結果は残りを行います。
難しい部分は、悪いコードの構成要素（およびすぐに優れたデザインを思い付く才能）の感覚を開発することは、開発で学ぶのが難しいスキルの1つであるということです。私の提案は、チーム内でこれを行うことができる十分な年長の誰かがいるという希望にかかっています-そのように人々を説得することははるかに簡単です。
編集-もう少し情報：
一般的に、あなたの問題はゲーム開発に限定されるとは思いません。根本的に、それはソフトウェアエンジニアリングの問題なので、その方向での私のコメントです。異なるのは、ゲーム開発業界の性質であり、他のタイプの開発よりも多くの結果と期限が必要かどうかはわかりません。
ただし、特にゲーム開発については、「特にゲームアーキテクチャ」のヒントに関するStackOverflowのこの質問に対する受け入れられた回答は次のように述べています。
オブジェクト指向設計の堅実な原則に従う....
これは基本的にまさに私が言っていることです。プレッシャーにさらされていると、大きなコードを書いていることに気づきますが、技術的な負債であることを頭に掘り下げました。私にとってはうまくいく傾向がありますが、1日の前半（または4分の3）を費やして中品質のコードを大量に生成し、しばらく休んでからしばらく考えます。コードを少し改善する方法について、頭の中で、または紙/ホワイトボードで少しデザインをしてください。多くの場合、繰り返しコードに気づき、物事を分割することでコードの総行数を実際に減らすことができますが、それでも読みやすさが向上します。今回は投資額が非常に速いので、「投資」と呼ぶのは馬鹿げているように思えます。多くの場合、半日（1週間後）に無駄になった可能性のあるバグを拾います。
- コードを作成したその日に修正します。
- あなたは数時間以内に喜んでいるでしょう。
上記を実際に信じることは困難です。何度も何度も効果を経験したからこそ、自分の仕事のためになんとかできました。それでも、コードを修正することを正当化することは、私にとってまだ難しいことです。残念ながら、このアドバイスはおそらくあまりにも一般的すぎて、簡単ではありません。しかし、私はそれを強く信じています！:)
特定の例に答えるには：
ボブおじさんのクリーンコードは、高品質のコードがどのようなものであるかを要約するという素晴らしい仕事をしています。私はたまたまその内容のほぼすべてに同意します。したがって、30000 LOCマネージャークラスの例を考えると、「正当な理由」の部分には本当に同意できません。私は不快に聞こえたくありませんが、そのように考えると問題につながります。単一のファイルにそれほど多くのコードがある理由はありません-それはほぼ1000ページのテキストです！ローカリティの利点（実行速度、または設計の「単純さ」）は、開発者がその怪物をナビゲートしようとして完全に動きが取れなくなることによって直ちに無効になります。
確信が持てない場合は、上記の本のコピーを入手して、それを一読することをお勧めします。この種の考え方を適用すると、きれいで自明なコードを自発的に作成することにつながります。