OOPの過度の複雑化に対する用語はありますか？

1〜2年前、OOP（Java）に関する優れた記事を目にしました。この記事では、2、3行のコードからなる単純な具体的なロガーの進行と、基本的には必要に応じてこれを追加してください！ 記事の終わりまでに、この単純なロガーはごみの巨大な混乱であり、元の開発者は自分自身をほとんど理解できませんでした...

このタイプの過剰合併症に共通の用語はありますか？その記事（私は再び見つけられることを心から願っています）は、孤立したケースのコンセプトを素晴らしく示していますが、パターン、フレームワーク、ライブラリの過剰使用によって開発者が本質的に自分自身を結び目にプログラムしたプロジェクト全体に出くわしましたその他の問題。独自の方法で、これは、交換用に継承する従来のVB6スパゲッティアプリと同じくらい悪い（またはさらに悪い）です。

私が本当に探しているのは、面接時にこれを持ち出すことです。アーキテクチャ/事前計画の欠如でこれに陥るのがどれほど簡単かを誰かが認識し、意識しているかどうかを知りたい（そして、彼らが適切なバランスを持っているように見えるかどうかで落ち込む）が、それは本当に何かではない私は多くの情報を見つけることができます。

そのような設計を説明するために私が聞いた最も頻繁な用語は過剰設計です。ただし、その言葉の本来の意味はソフトウェア開発とは関係がなく、ソフトウェア開発以外ではおそらくそれほど悪い調子ではありません。

より一般的なレベルでは、Joel Spolskyは、建築設計を過度に複雑にするデザイナーに「architecture astronauts」という名前を付けました。

しかし、特にインタビューの場合、実際に必要なものだけをデザインに入れて、不健康な「念のため」のアプローチを忘れてしまい、これがYAGNI原則と呼ばれる、反対の名前を知ることがより重要だと思います。

はい、オーバーエンジニアリングはこれを説明する最も簡単な用語です。長年にわたって覚えていた以上に、過剰に設計された、不必要に複雑なデザインを見てきました。何年も前、Microsoft GWBasicコースを受講する際に、インストラクターはKISSメソッド（Keep it Simple Stupid）を繰り返し打ちました。これは当時と同じように今日も真実です。

ですから、私は常にKISSを覚えており、常にSOLID Principlesを念頭に置いて設計しています。しかし、そうは言っても、SOLIDの原則を十分に考慮して設計をオーバーエンジニアリングすることは可能です。常識、実用的なアプローチと、純粋であり、一般に受け入れられるOOPガイドラインを遵守するという願望とのバランスを取る必要があります。十分な時間を与えられ、複雑なソリューションを作成するのが好きなら、スケートボード用のエンジンを設計する道をたどることができます。最終的には車になると思ったからです。幸いなことに、私は長年にわたってこれを行わないように十分に訓練されてきましたが、私は何度もそれを見てきました。

まとめると、コードの過剰な複雑化を防ぐために：

1）KISS（Keep it Simple Stupid）

2）実用性を念頭に置いて、SOLID原則に従います。

3）すべての不測の事態に合わせて設計しようとしないでください。また、孤立した意図的なものであり、それらを防ぐ努力がそれらを維持する効果をはるかに上回る場合、時には小さく漏れやすい抽象化は恐ろしいものではありません。

4）ソリューションの設計中にソリューションの実装を検討します。「ああ、それは実装の詳細だ」と言うことはできず、設計が実用的であると想定することはできません。私はかつてこれを頻繁に行った建築家と仕事をしていましたが、悲しいかな、彼のデザインはうまくいきませんでした。

5）あなたがそれを維持しようとしている人であるかのようにコーディングします。

したがって、あなたはこのインタビューを受け、候補者をだましてソフトウェアエンジニアリングについて知っていることを表示するつもりです。そして、「いや、最初の課題で知っていることをすべて適用したいと思うでしょう。 、あなたは金メッキの過剰なビジネス価値のない創造者です！シュー！」

具体的な例を提示し、特定のパターンを適用することの長所と短所について議論する方が安全だと思います。「それは依存します、あなたはそれを速くしたいですか？これですべてでしょうか？問題はどれほど複雑ですか？どのパターンがすでに設定されていますか？」のような応答を求めるよりも。自分で何かを学ぶことができます。これにより、候補者は自分の文脈感覚を証明できますが、よりオープンな質問になります。特定の回答を待って欲しいと思うと、せいぜいあなたと同じ最大の懸念を持つ誰かを得るでしょう。答えが得られない場合、候補者はそれを簡単に考えている可能性があります。