ゴッドオブジェクト とは？

わかりやすいサインがあるよ。①ファイルが1000行を超えている、②メソッドが30個以上ある、③クラス名がManager、Handler、Processorなど曖昧、④import文が大量にある、⑤変更するたびに他の機能が壊れる。UserManagerが認証、メール送信、課金、ログ出力を全部やっているとかね

最初は小さなクラスだったのに、「ここに追加するのが楽だから」と機能を足し続けた結果。デッドラインに追われて設計を考える余裕がないと加速する。「動いているコードを分割するのは怖い」という心理も原因。技術的負債の典型パターンだよ

①まずテストを書いて安全網を作る、②関連するメソッドとフィールドをグループ化、③グループごとに新しいクラスに抽出（Extract Classリファクタリング）、④元のクラスは新しいクラスに委譲。一度に全部やらず、変更のついでに少しずつ分割する「ボーイスカウトルール」がおすすめだよ

①SOLID原則、特に単一責任の原則を意識する、②コードレビューでクラスの肥大化を早期に指摘する、③「このクラスの責務を一言で説明できるか？」を自問する。一言で説明できないなら責務が多すぎるサイン。CIにクラスの行数やメソッド数の警告を入れる方法もあるよ