「神のオブジェクト」が間違っていることをどのように証明または反証しますか？
問題の概要：
要するに、私はコードベースと、私が置き換えることを許可されていない開発チームを引き継ぎました。そして、神オブジェクトの使用は大きな問題です。今後、リファクタリングを行いたいのですが、神のオブジェクトですべてをやりたいというチームから「簡単だから」とプッシュバックを受けています。これは、リファクタリングができないことを意味します。私は長年の開発経験、これらのことを知るために雇われた新しい上司であるなどと引き合いに出して、サードパーティのオフショア会社のアカウント営業担当者もそう言いました。これは現在、経営幹部レベルと私の会議です明日です。ベストプラクティスを提唱するために、多くの技術的な弾薬を使いたいと思っています。長期的には安くなると思います（個人的には、サードパーティが心配していることです）。
私の問題は技術的なレベルからのものです。長期的には問題ありませんが、超短期間と6か月の期間で問題が発生しています。また、「知っている」ことはありますが、参考文献や外部のリソースでは証明できません。 1人のデータ（Robert C. Martin、別名Uncle Bob）です。1人のデータ（Robert C Martin）だけからのデータを持っていると言われたので、それは私が求められていることです。 。
質問：
「神」のオブジェクト/クラス/システムのこの使用は悪い（または私たちが探しているので良い）と明確に言う分野の有名な専門家が直接引用できるリソース（タイトル、発行年、ページ番号、引用）は何ですか最も技術的に有効なソリューションの場合）？
私がすでに行った調査：
- ここにはたくさんの本があり、それらの索引で「神オブジェクト」と「神クラス」という単語の使用を検索しました。奇妙なことに、ほとんど使用されておらず、たとえば私が持っているGoFの本のコピーは使用されていません（少なくとも私の目の前の索引によると）が、以下の2冊の本で見つけましたが、もっと欲しいです使うことができます。
- 私は "神のオブジェクト"のWikipediaページ とその現在の参照リンクが少ないスタブを確認したので、私はそれは個人的には同意するものの、個人的な環境で使用できるほど多くはありません経験は有効とは見なされません。引用された本はまた、私がこれらの技術的ポイントについて議論している人々によって有効であるには古すぎると考えられています。彼らがしている議論は、「かつてそれは悪いと考えられていたが誰もそれを証明できなかった。 「オブジェクトは使いやすい」。私は個人的にこの発言は正しくないと信じていますが、それが何であれ、真実を証明したいと思います。
- Robert C Martinの「アジャイル原則、パターン、およびC＃での実践」（ISBN：0-13-185725-8、ハードカバー）では、266ページに「神のクラスが悪い考えであることは誰もが知っています。私たちは望んでいません。システムのすべてのインテリジェンスを単一のオブジェクトまたは単一の関数に集中させること。OODの目標の1つは、動作を多くのクラスと多くの関数に分割して分散することです。」 -そして、時にはとにかく時々とにかく神のクラスを使用する方が良いと言い続けます（例としてマイクロコントローラーを引用）。
- Robert C Martinの「Clean Code：A Handbook of Agile Software Craftsmanship」ページ136（そしてこのページのみ）で「神のクラス」について語り、「クラスは小さいほうがよい」ルール違反の主な例としてそれを呼びかけています彼は138ページから始まる「単一責任原則」の推進に使用しています。
私が抱えている問題は、すべての参照と引用が同じ人物（Robert C. Martin）からのものであり、同じ1人の人物/ソースからのものであるということです。彼はただの見方なので、「神のクラス」を使用しないという私の願望は無効であり、ソフトウェア業界の標準的なベストプラクティスとして受け入れられていないと言われています。これは本当ですか？ボブおじさんの教えを守ろうとすることで、技術的な観点から間違ったことをしていますか？
神のオブジェクトとオブジェクト指向プログラミングとデザイン：
OOPそしてそれが明示的に呼び出されることは決してありません;良いデザインへの暗黙は私の考えです（自由に私を修正してください） 、私が学びたいので）、問題は私がこれを「知っている」ことですが、誰もがそうしているわけではありません。したがって、実際にはほとんどの人が実際にそれを普遍的な真実として効果的に呼び出しているので、この場合は有効な議論とは見なされません統計的にほとんどの人はプログラマではないので、統計的にそれを知らない。
結論：
彼らが技術的な主張をしていて、真実を知り、本当のエンジニア/科学者のような引用でそれを証明できるようにしたいので、引用する最良の追加結果を得るために何を検索するか迷っています神のオブジェクトを使用したコードの個人的な経験のため、私は神のオブジェクトに偏っています。どんな援助や引用でも深く感謝します。
既存のデザインによって作成された問題点を特定することで、プラクティスの変更のケースが作成されます。具体的には、既存の設計、壊れやすいもの、現在壊れているもの、単純な方法で実装できない動作（直接的またはいくらか間接的なもの）のために、本来あるべきものよりも難しいものを特定する必要があります。現在の実装、または場合によってはパフォーマンスへの影響、新しいチームメンバーの速度を上げるのにかかる時間など。
第2に、作業コードは理論や優れた設計に関する議論よりも優先されます。残念ながら、これは悪いコードにも当てはまります。したがって、より良い代替案を提供する必要があります。つまり、より優れたパターンと実践を提唱しているため、より優れたデザインを引き出すためにリファクタリングする必要があります。既存の設計を通して、狭いトレーサーバレットスタイルの平面を見つけ、おそらく1回目の繰り返しでは、神オブジェクトの実装を機能させたまま、実際の実装を新しい設計に委ねるソリューションを実装します。次に、この新しいデザインを利用するコードを記述し、パフォーマンス、保守性、機能、バグや競合状態の修正、または開発者の認知的負荷の削減など、この変更によって得られるメリットを披露します。
多くの場合、設計が不十分なシステムで攻撃するのに十分小さな表面積を見つけることは困難です。初期値を提供するのに時間がかかる場合があり、初期の見返りはそれほど印象的ではないかもしれませんが、作業することもできます新しいアプローチの擁護者を見つけるために、少なくとも同情的なチームメンバーとペアを組む場合。
神オブジェクトの嘆きは、合唱団に説教しているときにのみ機能します。これは問題に名前を付けるためのツールであり、問題を解決するために十分にやる気があり、先輩であり、それについて何かをするのに十分な動機がある受容的な聴衆を持っている場合にのみ機能します。神のオブジェクトを修正することは議論に勝ちます。
あなたの当面の懸念は経営者の賛同にあると思われるので、このコードを置き換えることは戦略的な目標である必要があると主張し、それを担当するビジネス目標に結び付けることが最善の策だと思います。私は、最初に、それを置き換えるために何をすべきかについて技術的な急上昇に取り組むことによって、いくつかの技術的な方向性を提供できるケースを作ることができると思います。
あなたはあなたの議論を正当化するのに十分なリソースを見つけたと思います。そのような会議の人々は、あなたの研究の要約にのみ注意を払い、2つまたは3つの裏付けとなる情報源について言及した後は聞き取りを停止します。最初に焦点を当てるのは、目に見える問題を解決するために購入することであり、必ずしも他の誰かが間違っている、または自分自身を正しくしているとは限りません。これは社会的な問題であり、論理的な問題ではありません。
テクノロジーリーダーシップの役割では、イニシアチブのいずれかをビジネス目標に結び付ける必要があるため、幹部にあなたの主張をするための最も重要なことは、それらの目的のために仕事が何をするかです。あなたはまた「新しい人」と見なされているので、人々が彼らの仕事を捨てることを期待することも、急速に並ぶことを期待することもできません。あなたが提供できることを証明することにより、ある程度の信頼を築く必要があります。長期的な懸念として、リーダーシップの役割では、結果に焦点を当てることを学ぶ必要もありますが、必ずしも結果の詳細にこだわる必要はありません。これで、戦略的な方向性を提供し、チームの進行から戦術的な障害を取り除き、チームメンターシップを提供することができます。自分のチームメンバーとの信頼の戦いに勝つことはできません。
ゲームにスキンがなければ、トップダウンの決定を下すことはほとんど信頼できません。何度も同じような状況にある場合は、状況が制御不能になったとエスカレートするのではなく、組織内のコンセンサス構築に重点を置く必要があります。
しかし、あなたが今どこにいるかを考えると、あなたの最善の策は、あなたの経験があなたの経験に基づいて測定可能な長期的な利益をもたらすこと、そしてボブおじさんやcoのような有名な開業医の仕事と一致していることを主張することです。 、そして数日/数週間を費やして、最高の対価の側面の狭いリファクタリングを例に説明し、優れたデザインの見方がどのようになるかを示します。ただし、ケースは、個人的な好みを超えて特定のビジネス目標に合わせる必要があります。
まず、測定可能な組織が業界のベストプラクティスを採用する必要があることを示す必要があります。 「それは私たちのために働くだけです！」単に予測できないため、時間でもリソースでも測定できません。ソフトウェアエンジニアリングは他の科学分野と同様に科学であり、これらの概念は研究、調査、テスト、および文書化されています。
ソフトウェアエンジニアリングでは、アンチパターン（またはアンチパターン）は、社会的またはビジネスオペレーションまたはソフトウェアエンジニアリングで一般的に使用される可能性のあるパターンですが、実際には非効率的または逆効果です。
Google IO 2009年の会議 では、この主題はMVPパターンが説明されたときに部分的に説明されていました。神オブジェクトとは関係ないかもしれませんが、弾薬。
また、このアンチパターンを使用すると、オブジェクト指向の設計で 単一責任の原則 に違反します。
すべてのクラスは単一の責任を持つ必要があり、その責任はクラスによって完全にカプセル化される必要があります。すべてのサービスは、その責任と密接に連携している必要があります。
Decaying Code ブログでも、これとその解決策について説明しています。
オブジェクト coupling について語らずに、単一責任の原則について語ることはできません。
[...]結合または依存関係は、各プログラムモジュールが他の各モジュールに依存する度合いです。
密結合システムがあると、
Assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency.オブジェクト結合のレベルが高いほど、まとまりが少なく、その逆も同じです。神のオブジェクトは、必要以上に知っている密結合の良い例であり、責任を過負荷にして、コードの再利用性を大幅に制限します。複雑なアプリケーションを設計するときは、 simplicity が頭に浮かぶ必要があります。大きな問題はより小さな問題に分解する必要があり、管理、テスト、文書化が容易になります。これは、オブジェクト指向のパラダイムで特に当てはまります。
この議論では、アンチパターンの議論にループバックしますが、このパラダイムはパターン、実世界のオブジェクト表現、そして最終的にはデータのカプセル化に関するものです。
これらの「良い習慣」は教室でより多く存在していると言うとき、あなたは正しいです。しかし、私は大学（および一部の大学）での教育経験があり、これらの原則が大学、特に工学部で教えられているのを見ただけです。悲しいです。しかし、他の良い習慣と同様に、自分自身を改善しようと努力する人は通常、基本的な 設計パターン を学び、最終的には結合と結束をジャングルする方法を理解します。
私が通常生徒に教えることは、それはmay良いプログラミング標準を採用するためにより多くの努力を必要とするようですが、それはalways長期的に見れば見返りがあります。良い例は、プログラマにソート関数を書くように依頼することです。プログラマーには2つの選択肢があります。 1）要素のリストが大きくなると持続できないクイックバブルソート関数（5分未満）を記述します。または2）スケーリングが向上する、より複雑な（別名最適化された）ソートアルゴリズム（クイックソートなど）を記述します。より大きなリストで。
ああ、私は行きます、別の古い質問を壊滅させます、しかし私はあなたがこの議論に勝たなかったと思います、そしてここに理由があります。
文化の問題のように聞こえる
あなたは彼らのマネージャーですが、彼らを置き換えることはできません。マネージャーに行って、彼らがやるべきことを実行させる必要があります。この場合、私は少なくとも神とそれを打ち消すことになると思います前方に移動するオブジェクト。それは、それが生まれた文化を反映する古典的なコードのケースのように私に聞こえます。つまり、神のオブジェクトは、この会社がどのように機能するかです。何か意味のある変更を加えたいですか？すべての決定は明らかに上部でクリアする必要があるため、最終的には常に同じ場所に行くことになります。
レガシーコードのクリーンアップとコードポリシーの変更で何度も失敗した試みに精通していたので、私は今、その文化がまだしっかりと定着しているか、少なくとも、その文化がまだ定着している場合、最初からコードを可能にした文化に対抗することはできないと思います。文化は非常に難しい上り坂であり、誰もが私に十分に支払うことができず、それが再び成功する可能性が高い価値のある努力であると感じるのに十分な力を私に与えることはほとんどありません。
変更が行われる前に、彼らは変更する動機を持たなければなりません。残念ながら、Stackを読むのに十分な量のプログラマーが時々スタックを読むので、全員が同じものに動機付けされているわけではないことを理解するのは困難です。私の経験では、多くの合理的な議論に勝ちましたが、結局のところ、会社は何らかの理由で知的に怠惰な開発者に苦しんでいます。
たぶん、ビジネスの懸念は、来週や5年後ではなく明日だけを考えるように動機付けられています（黙示録の場合に北極圏に種子保管庫を建てた国からの移民の子供である場合、特に苛立たしいシナリオです）。多分彼らは変化を恐れています。おそらく、彼らは年功序列を過大評価しているため、開発チームのリーダーやマネージャーを招集するために外部から雇う必要がある場合でも、指揮系統は無意味であり、すべての生涯のチームの誰も十分に成長していないと認識しています。そこに（または言われた生命家が責任と関連付けられる危険を望まないので）。または、これを見たことがあります。多分それは平凡を擁護する非常に現実的で憂鬱な現象です。なぜなら、それは品質と競争することができないことを深く知っているためです。すべてが定期的にばらばらになったときに責任があります。
最終的には恐怖や壊れた指標に根ざした問題をどのように戦って成功しますか？これをお伝えします。これは、熱心な品質の開発チームよりもはるかに多くかかり、このQが投稿されたときのサウンドからはそれよりはるかに少ないものでした。
それは扱いにくい文化の問題ではないという不可能ではない出来事において...
現在、トップの人々は変化に非常に敏感で、彼らが実際にあなたがそれを成し遂げることを望んでいると仮定すると、お金と機会の喪失ですべての議論に時間をかけるだけで十分です。
このとんでもないコードベースで新しい人を訓練するのに時間がかかるたびに、変更または新しい機能を何かに追加するのに時間がかかるたびに、パートナーとなる会社から別のシステムにエンドポイントを公開することが非常に困難になるたびに、それはお金がかかります。恐ろしいお金がたくさん。最も重要なのは、より機敏な小規模の競争相手が急降下するためのウィンドウを開いたままにし、あなたにできることは非常にゆっくりと反応すること、そして最終的にはあなたからすべてを奪うことです。
特に頑固で愚かな文化は、会社の実際の物理的な屋根が実際にそのために燃えている場合でも、すべてのコストで現状を維持することを認識してください。
最も基本的なOOPルーズカップリングや高い凝集性などの原則のいくつかを引用できます。「神オブジェクト」は、関連のないクラスを結合し、凝集性が低いように聞こえます。
ボブおじさんにいつでも尋ねることができます。
問題は、それがいったん綴られれば、多数の作者によって再参照される必要がないことは、どんな感覚を持つ人々にとっても明白であることです。ソースは1つだけ必要です。
出典を探す際に始めたいと思われるその他の用語は次のとおりです。
- SOLID
- デメテルの法則
- 泥の大玉
これらはすべて、実際にそのような名前を付けていなくても、実行可能な参照ソースを生成する可能性のある関連する概念を表しています。
結局のところ、あなたはボスです。それをする理由は、あなたがそう言うからであり、良いマネージャーと見なされるために、あなたは本当にあなたの決定を正当化する準備ができているべきです。あなたはそれをしました、そしてそれでも抵抗があるならば、彼らが言われたようにあなたのチームがするための正しい行動方針はです。
「神」のオブジェクトが間違っていることをどのように証明または反証しますか？
それはいけません。
この種の推測は数学的証明に適していません。数学的証明は健全な唯一の種類の証明です。
「間違った」感情的な単語を、神のオブジェクトを使用した効果の定量化可能な測定値で置き換えようとしても、次のことがわかります。
- 利用可能な対策は粗雑です、
- プロのプログラマーが作成したコードに対してこれらの測定値が定量化された信頼できる研究はほとんどありません
- 言語構造またはデザイン（アンチ）パターンがこれらの測定値に関連付けられている信頼できる研究はほとんどありません。
そして、それは特定のオブジェクトが「神」オブジェクトであるときを決定する問題を無視しています。
せいぜい、これらの種類の研究は、経験的な相関関係を示すことができるだけでした。本物の証拠ではありません。
あなたが実際にしていることはdebating他の人々の変化を視野に入れて「神」オブジェクトの長所と短所opinions ...そしてあなたの組織の慣行です。
「証明」のような言葉は使わないでください。そうしないと、論争している人々があなたの顔を笑う傾向があります。
今週の第一人者＃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