「神のオブジェクト」が間違っていることを証明または反証するにはどうすればよいですか？

問題の概要：

長い話を簡単に言えば、私はコードベースと開発チームを引き継ぎました。私はこれを置き換えることは許されておらず、God Objectsの使用は大きな問題です。今後、リファクタリングをしてもらいたいのですが、「もっと簡単だから」、God Objectsを使ってすべてをやりたいチームから押し戻されています。これは、リファクタリングが許可されないことを意味します。私は長年の開発経験、これらのことを知るために雇われた新しいボスなどを押し返しました。また、サードパーティのオフショア会社が営業担当者を説明しました。これは現在、役員レベルと会議です明日であり、長期的にはより安くなると思うので、多くの技術的な弾薬を使ってベストプラクティスを提唱したいと思います（そして、個人的にはサードパーティが心配していることだと感じています）。

私の問題は技術レベルからのものであり、長期的にはよく知っていますが、超短期間と6か月の期間には問題があります。 1人（ロバートC.マーティン、別名ボブおじさん）の、1人のデータ（1人のみ）（ロバートCマーティン）が十分な議論をしていないと言われているように。

質問：

「神」オブジェクト/クラス/システムのこの使用は明らかに悪いと言っている分野の有名な専門家が直接引用できるリソース（タイトル、発行年、ページ番号、引用）は何ですか？最も技術的に有効なソリューションの場合）？

私がすでに行った研究：

1. ここにはたくさんの本があり、「god object」と「god class」という言葉の使用についてインデックスを検索しました。奇妙なことに、ほとんど使用されておらず、たとえば、私が持っているGoF本のコピーは使用されません（少なくとも私の目の前のインデックスによると）が、下の2冊の本で見つけましたが、もっと欲しい私は使えます。
2. ウィキペディアのページで「God Object」と現在の参照リンクの少ないスタブを確認したので、個人的には有効とは見なされない環境ではあまり使用できないと言うことには個人的に同意します。引用された本はまた、私がこれらの技術的ポイントを議論している人々によって有効であるには古すぎると考えられています。 「オブジェクトは使いやすい」。私は個人的にこの声明が間違っていると信じていますが、それが何であれ真実を証明したいと思います。
3. ロバートCマーティンの「C＃のアジャイルの原則、パターン、および実践」（ISBN：0-13-185725-8、ハードカバー）では、266ページに「神のクラスが悪い考えであることを誰もが知っています。システムのすべてのインテリジェンスを単一のオブジェクトまたは単一の機能に集中させること。OODの目標の1つは、動作を多数のクラスおよび多数の機能に分割および分散することです。-そして、とにかく時々神のクラスを使用する方が良いことを時々言い続けます（例としてマイクロコントローラーを引用）。
4. ロバートCマーティンの「クリーンコード：アジャイルソフトウェアクラフツマンシップハンドブック」136ページ（およびこのページのみ）で、「神のクラス」について説明し、「クラスは小さくなければならない」ルールの違反の主な例として呼び出しています彼は138ページから始まる単一責任原則の推進に使用しています。

私が抱えている問題は、すべての参考文献と引用が同じ人（ロバートC.マーティン）から来ており、同じ一人の人/情報源から来ていることです。彼はただ一つの見解であるため、「神クラス」を使用しないという私の願望は無効であり、ソフトウェア業界の標準的なベストプラクティスとして受け入れられないと言われています。これは本当ですか？ボブおじさんの教えを守ろうとすることで、技術的な観点から間違ったことをしているのでしょうか？

神のオブジェクトとオブジェクト指向プログラミングおよび設計：

これについて考えるほど、OOPを勉強するときに学ぶことが多くなり、明示的に呼び出されることはありません。良いデザインへのその暗黙は私の考えです（私が学びたいので、自由に訂正してください）、問題は私がこれを「知っている」ことですが、誰もがそうではありません。統計的にほとんどの人はプログラマーではないため、実際にはほとんどの人が統計的に無知であるにもかかわらず、私は事実上それを普遍的な真実と呼んでいます。

結論：

彼らが技術的な主張をしており、真実を知り、実際のエンジニア/科学者のような引用でそれを証明できるようにしたいので、引用する最良の追加結果を得るために何を検索するのか迷っています私は、神のオブジェクトを使用したコードの個人的な経験のために、神のオブジェクトに偏っています。どんな援助または引用も深く感謝されるでしょう。

既存の設計によって作成された問題点を特定することにより、プラクティスの変更が必要になります。具体的には、既存の設計のために本来あるべきものよりも難しいもの、壊れやすいもの、今壊れているもの、どのような動作を単純な方法で直接（またはやや間接的でも）実装できないものを識別する必要があります現在の実装、または場合によってはパフォーマンスの低下、新しいチームメンバーをスピードアップするのにかかる時間など。

第二に、実用的なコードは、理論や優れた設計に関する議論よりも優先されます。残念ながら、これは悪いコードでも当てはまります。そのため、より良い代替案を提供する必要があります。つまり、より良いパターンと実践の支持者として、より良いデザインを引き出すためにリファクタリングする必要があります。既存の設計から狭い、トレーサー、弾丸スタイルのプレーンを見つけ、おそらく反復1のために、ゴッドオブジェクトの実装を機能させるが、実際の実装は新しい設計に任せるソリューションを実装します。次に、この新しい設計を活用するコードを作成し、パフォーマンス、保守性、機能、バグや競合状態の修正、開発者の認知的負荷の軽減など、この変更により勝つことを示します。

よく設計されていないシステムで攻撃するのに十分な小さな表面積を見つけることは多くの場合、困難です。初期値を提供するのに必要な時間よりも長くかかる場合があります。少なくとも少し同情的なチームメンバーとペアを組む場合、新しいアプローチの支持者を見つけることについて。

神オブジェクトの嘆きは、合唱団に説教しているときにのみ機能します。それは問題に名前を付けるためのツールであり、シニアであり、それについて何かをするのに十分なモチベーションのある受容的な聴衆がいるときにのみ問題を解決するために機能します。神オブジェクトを修正すると、議論に勝ちます。

あなたの差し迫った懸念は経営陣の賛同であるように見えるので、このコードを置き換えることは戦略的な目標であり、あなたが責任を負うビジネス目標に結びつける必要があると主張するのが最善だと思います。私はあなたがそれを置き換えるために何をすべきかについての技術的なスパイクに最初に取り組むことによって、いくつかの技術的な方向性を提供できるというケースを作ることができると思います、できれば現在の設計について予約をしている1人または2人の技術者からのリソースを巻き込みます。

議論を正当化するのに十分なリソースを見つけたと思います。そのような会議の人々はあなたの研究の要約にのみ注意を払い、あなたが2つまたは3つの裏付けとなる情報源に言及した後、彼らは耳を傾けなくなります。あなたが最初に焦点を当てるのは、他の誰かが間違っているか自分自身が正しいことを必ずしも証明するのではなく、あなたが見ている問題を解決するために買収することです。これは論理的な問題ではなく、社会的な問題です。

テクノロジーリーダーシップの役割では、イニシアチブをビジネス目標に関連付ける必要があります。そのため、経営幹部にあなたの主張を伝えるために最も重要なことは、その目標のために仕事が何をするかです。あなたは「新人」とも考えられているので、人々が自分の仕事を捨てたり、急速に列に並ぶことを期待することはできません。提供できることを証明して、信頼を築く必要があります。長期的な懸念として、リーダーシップの役割では、結果に集中することを学ぶ必要もありますが、必ずしも結果の詳細に執着する必要はありません。戦略的な方向性を提供し、チームの進捗状況から戦術的な障害を取り除き、チームのメンターシップを提供します。自分のチームメンバーとの信頼の戦いに勝つことはできません。

トップダウンの決定を下すことは、ゲームにスキンがない限りほとんど信頼できません。同様の状況が繰り返し発生する場合は、状況が制御不能になったと感じたらエスカレートするのではなく、組織内でのコンセンサス構築に重点を置く必要があります。

しかし、あなたが今いる場所を考えると、あなたの最善の策は、あなたのアプローチがあなたの経験に基づいて測定可能な長期的な利益をもたらすこと、そしてそれが叔父ボブやコのような有名な開業医による仕事と一致していると主張することです。 、優れたデザインの見方がどのように見えるべきかを実証するために、最高の価値のある見返りの狭いリファクタリングの例を中心に数日/週を費やすことを望みます。ただし、個人的な好みを超えて、特定のビジネス目標に合わせてケースを調整する必要があります。

まず、測定可能な組織は業界のベストプラクティスを採用する必要があることを提示する必要があります。「それはちょうど私たちのために働く！」と言って 単に予測できないため、時間的にもリソース的にも測定することはできません。ソフトウェアエンジニアリングは他の科学分野と同様に科学であり、これらの概念は研究、研究、テスト、および文書化されています。

1. 神のオブジェクトがあるアンチパターンと述べています

   ソフトウェアエンジニアリングでは、アンチパターン（またはアンチパターン）は、社会的またはビジネス上の運用またはソフトウェアエンジニアリングで使用されるパターンであり、一般的に使用される可能性がありますが、実際には非効率的および/または逆効果です。

2. 2009年のGoogle IO会議では、MVPパターンが説明されたときにこの主題が部分的に説明されました。それは神のオブジェクトとは関係ないかもしれませんが、弾薬を与えるかもしれません。

3. また、このアンチパターンを使用すると、オブジェクト指向設計の単一の責任原則に違反します。

   すべてのクラスには単一の責任があり、その責任はクラスによって完全にカプセル化される必要があります。すべてのサービスは、その責任と密接に連携する必要があります。

4. 腐朽コードのブログにもこのことについて、それの解決策について語っています。

5. オブジェクトカップリングについて話さずに単一の責任原則について話すことはできません。

   [...]カップリングまたは依存関係は、各プログラムモジュールが他の各モジュールに依存する度合いです。

   密結合システムがあるとassembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency.、オブジェクトの結合レベルが高くなると凝集度が低くなり、逆も同様です。神オブジェクトは、必要以上に知っているため、密結合の良い例です。したがって、責任を持ちすぎて、コードの再利用性を大幅に制限します。

6. 複雑なアプリケーションを設計するときは、単純さを念頭に置く必要があります。大きな問題は小さなものに分解する必要があり、管理、テスト、文書化が容易です。これは、オブジェクト指向のパラダイムでは特に当てはまります。

   この引数を使用して、アンチパターン引数にループバックしますが、このパラダイムは、パターン、実世界のオブジェクト表現、および最終的にはデータのカプセル化に関するものです。

7. これらの「良い習慣」は教室でより存在すると言うとき、あなたは正しい部分です。しかし、私は大学（およびいくつかの大学）で教育経験があり、大学、特に工学部でこれらの原則が教えられているのを見ました。悲しいですね。しかし、他の優れた実践と同様に、自分自身をより良くしようと努力する人は、通常、いくつかの基本的な設計パターンを学び、最終的に結合と結合の間のジャングルの方法を理解します。

   私が通常学生に教えることは、良いプログラミング標準を採用するためにより多くの努力を必要とするように思えるかもしれませんが、それは常に長期的に見返りがあります。良い例は、ソート関数を書くようプログラマーに頼む人です。プログラマーには2つの選択肢があります。1）要素のリストが大きくなると持続不可能なクイックバブルソート関数（5分未満）を記述する、または2）スケーリングがより複雑な（最適化された）ソートアルゴリズム（クイックソートなど）を記述するより大きなリストで。

ああ、私は別の古い質問を壊して行きますが、あなたはこの議論に勝てなかったと推測するでしょう、そして、ここに理由があります。

文化問題のように聞こえる

あなたは彼らのマネージャーですが、あなたは彼らを取り替えることができず、彼らがあなたが彼らがしているべきであると信じていることをさせるためにあなたのマネージャーに行かなければなりません。前方に移動するオブジェクト。生まれた文化を反映したコードの古典的なケースのように思えます。言い換えれば、神のオブジェクトはこの会社の仕組みです。何らかの意味のある変更を行いたいですか？すべての決定は明らかにトップでクリアする必要があるため、最終的には常に同じ場所に移動します。

レガシーコードのクリーンアップとコードポリシーの変更で複数回失敗した試みに関与していた私は、その文化がまだしっかりと定着している、または少なくとも戦いながら、最初にコードを可能にした文化と戦うことはできないという意見です文化は非常に難しい上り坂のスローガンであり、誰も私に十分なお金を払ったり、それが再び成功する価値のある努力であると感じるほどの力を与えてくれそうにない。

変化が起こる前に、彼らは変化するように動機付けられなければなりません。残念ながら、時々スタックを読むのに十分なことをするプログラマーとして、すべての人が同じものに動機付けられているわけではないことを理解するのは難しいです。私の経験では合理的な議論の多くを獲得しましたが、結局のところ、会社は理性的に怠zyな開発者に何らかの理由で苦しんでいます。

たぶん、ビジネス上の懸念は、来週や5年後ではなく、明日だけを考えるように動機付けられたかもしれません（黙示録の場合に北極圏に種子保管庫を建設した国からの移民の子供である場合、特にイライラするシナリオ）。彼らは変化を恐れているのかもしれません。多分、彼らは開発チームのリーダーやマネージャーを雇うために外部から雇わなければならない場合でも、彼らのオールライフチームの誰もが十分に成長していないことを認識しているので、指揮系統が無意味であるほど過度に年功を重んじている（または、生命体が責任に伴うリスクを望まないため）。または、私はこれを見ましたが、おそらくそれは平凡さを擁護する非常に現実的で憂鬱な現象です。

最終的に恐怖や失敗したメトリックに根ざした問題をどのように解決しますか？私はこれをあなたに伝えます、それはコミットされた品質の開発チームよりもはるかに多くを必要とし、あなたはこのQが投稿されたときの音からそれよりもはるかに少なかった。

それは手に負えない文化の問題ではない不可能ではないイベントで...

今、トップの人々は変化を受け入れることを非常に受け入れやすく、実際に彼らがあなたを信頼してくれると仮定すると、あなたは本当にあなたの議論のすべてをお金と機会の喪失で中断するだけです。

このとんでもないコードベースで誰かを訓練するのに時間がかかるたびに、何かに新しい機能を変更または追加するのに時間がかかるたびに、パートナーにしたい会社の別のシステムにエンドポイントを公開するのが非常に難しくなるたびに、それはお金がかかります。おかしなお金がたくさん。最も重要なことは、ウィンドウを開いたままにして、より機敏な小規模の競合他社が急襲し、あなたができることはそれらにあまりにもゆっくりと反応し、最終的にはあなたからすべてを奪うことです。

特に頑固で愚かな文化は、会社の実際の物理的な屋根が実際に燃えている場合でも、現状を維持します。

疎結合や高凝集度など、最も基本的なOOPプリンシパルの一部を引用できます。「神オブジェクト」は、無関係のクラスを結合し、凝集度が低いように聞こえます。

いつでもボブおじさんに聞くことができます。

問題は、ひとたび説明すれば、多くの著者が再参照する必要がないという感覚を持っている人々にとって非常に明白だということです。必要なソースは1つだけです。

ソースを探すときに開始する可能性のある他の用語は次のとおりです。

• 固体
• デメテルの法則
• 泥の大玉

これらはすべて、実際に参照ソースとして名前を付けていない場合でも、実行可能な参照ソースを生成する可能性のある関連概念を表しています。

最終的には、あなたは上司です。そうする理由は、あなたがそう言うからです。そして、良いマネージャーと見なされるために、あなたは本当にあなたの決定を正当化する準備ができているべきです。あなたはそれをやった、そしてまだ抵抗があるなら、正しい行動はあなたのチームが言われたとおりにすることだ。

「神」オブジェクトが間違っていることを証明または反証するにはどうすればよいですか？

できません。

この種の推測は数学的な証明の対象ではなく、数学的な証明が唯一の健全な証明です。

感情的な言葉「間違った」を、神のオブジェクトを使用した効果の定量化可能な尺度に置き換えようとしても、次のことがわかります。

1. 利用可能な測定は粗雑であり、
2. プロのプログラマーによって作成されたコードについてこれらの測定値が定量化された信頼できる研究はほとんどありません
3. 言語の構成またはデザイン（反）パターンがこれらの手段に結び付けられている信頼できる研究はほとんどありません。

そして、それは特定のオブジェクトが「神」オブジェクトであるかどうかを決定する問題を無視しています。

せいぜい、これらの種類の研究は経験的な相関関係を実証することしかできませんでした。本物の証拠ではありません。

あなたが実際にやっているのは、他の人々の意見を変えることを視野に入れて「神」オブジェクトの長所と短所を議論することです...そしてあなたの組織の慣行です。

「証明」のような言葉を使わないでください。さもなければ、あなたが議論している人々はあなたの顔で笑いがちです。

今週の第一人者＃84をご覧ください。それはすべて、神のオブジェクト（モノリス）とそれらがいかに悪いかについてです。

エキス：

（メジャー）クラス内の潜在的に独立した機能を分離します[...]（マイナー）新しい機能でクラスを拡張することを思いとどまらせることができます[...]

あなたのチームが「神の天体は間違っている」という学問的証明に本当に興味があるのか​​どうか、私はわからない。

心理学の観点からは、リファクタリングのアプローチは、チームの能力を攻撃するものとして誤解される可能性があります。プログラムは期待どおりに機能していますが、「チームは悪い仕事をしました」。

あなたが本当にやりたいことは、「スパゲッティコード」と「神オブジェクト」のマイナスの副作用に対処することです。副作用によって引き起こされるバグが増えるため、新機能を追加するためのコストを調査します。

答えを提供するのではなく、非常に具体的で質問をする方がより役立つ場合があります。

manager > Why did implement the new tax-calculation schema took more than 4 weeks
team > because {reason a}
manager > And why was {reason a}?
team > because {reason b}
manager > And why was {reason b}?
...
team > because {reason z}
manager > what could we do to avoid {reason z} ?
team > refactor code