ソフトウェア開発に適用される「オーバーエンジニアリング」という用語の適切な定義は何でしょうか。この表現は、ソフトウェア設計の議論の中で「過度の将来性」と関連して頻繁に使用されるようであり、より正確な定義を突き止めることができれば幸いです.
19 に答える
ほとんどの回答とは対照的に、「現在不要な機能」が過剰設計であるとは思いません。または、最も問題の少ない形式です。
あなたが言ったように、最悪のオーバーエンジニアリングは通常、将来の保証と拡張性の名目でコミットされ、正反対のことを達成します:
- 抽象化の空のレイヤーは、せいぜい不必要であり、最悪の場合、基礎となる API の狭い非効率的な使用に制限されます。
- 抽象ファクトリを介して取得された保護されたメソッドやコンポーネントなど、指定された「拡張ポイント」が散らばるコード - これらはすべて、機能を拡張する必要があるときに実際に必要なものではないことが判明します。
- 「ハードコーディングを回避する」ためにすべてを構成可能にすることで、構成ファイルにはソースコードよりも多くの (複雑で失敗しやすい) アプリケーションロジックが存在するという効果があります。
- 過剰な一般化: 開発者は、(技術的に興味のない) 機能仕様を実装する代わりに、ビジネス ユーザーから提供された仕様自体を「実行」する (技術的に興味深い) 「ビジネス ルール エンジン」を構築します。最終的な結果は、プロプライエタリ (スクリプトまたはドメイン固有) 言語のインタープリターであり、通常はひどく設計されており、ツールのサポートがなく、非常に使いにくく、ビジネス ユーザーが作業することはできません。
真実は、新しい要件や変化する要件に最も簡単に適応できる (したがって、最も将来性と拡張性が高い) 設計は、可能な限り単純な設計です。
私たちが過剰に設計されたものを考えてきた場合、それは常に、非常に汎用的に設計されているため、最初に実行するように設計された主なタスクを見失い、したがって使いにくくなるだけでなく、ソフトウェアを説明してきました。 、しかし、基本的に知的ではありません。
私にとって、オーバーエンジニアリングとは、必要のないもの、必要になるかどうかわからないものを含めることです。要件が特定の方法で変更された場合に機能が優れている可能性があると自分が言っていることに気付いた場合は、オーバーエンジニアリングである可能性があります。基本的に、オーバーエンジニアリングはYAGNIに違反しています。
この質問に対するアジャイルな答えは、要求された機能に貢献しないすべてのコードです。
Joel on Softwareには、次のような議論があります。
まだ存在していない想像上の将来の問題のために大規模なクラス階層を作成することは、一種のオーバーエンジニアリングであり、したがって悪いことです。
そして、実例を交えて議論に入る。
問題の起こりうる影響について考えることに多くの時間を費やし、結果として問題自体の解決を妨げてしまう場合は、オーバーエンジニアリングである可能性があります。
「エンジニアリングのベスト プラクティス」と「現実世界への適用性」の間には、絶妙なバランスがあります。ある時点で、特定のソリューションがエンジニアリングの観点から「純粋」ではない場合でも、それでうまくいくと判断する必要があります。
例えば:
高校の同窓会で一度だけ使用するユーザー管理システムを設計している場合、おそらく、信じられないほど長い名前や奇妙な文字セットのサポートを追加する必要はありません。妥当な最大長を設定し、基本的なサニタイズを行うだけで十分です。一方、何百もの同様のイベントに展開されるシステムを作成している場合は、問題にもう少し時間を費やすことをお勧めします。
目の前のタスクに適切なレベルの努力が必要です。
文脈に大きく依存しているため、正確な定義はおそらく不可能だと思います。たとえば、原子力発電所の制御システムよりも、きらびやかなポニーを表示するWebサイトをオーバーエンジニアリングする方がはるかに簡単です。冗長性、過度のエラーチェック、高度に計測されたロギング機能はすべて、きらびやかなポニーアプリ用に過剰に設計されていますが、原子力発電所の制御システム用には設計されていません。私ができる最善のことは、アプリケーションの目的のために機能に過度のオーバーヘッドを適用しているときの感覚を持っていることだと思います。
金メッキと過剰設計を区別することに注意してください。私の考えでは、金メッキは、求められておらず、決して使用されない機能を生み出しています。オーバーエンジニアリングとは、コードの周りにチェックをコーディングするか、単純なタスクに過度の設計を使用することによって、アプリケーションにどの程度の「安全性」を組み込むかということです。
これは、 「最も単純なアプローチは常に最良のアプローチである」という私の物議を醸すプログラミングの意見に関連しています。
私にとって、それはコードにこれ以上の脂肪を追加するものです。肉は仕様に従って仕事をするコードであり、脂肪はそれがより複雑になるような方法でコードを肥大化させるコードです。プログラマーは、機能の将来の拡張を期待していた可能性があります。でもそれでも太っている!
ここからの引用:「...実際に必要なときに実装し、必要になると予見したときではありません。」
あなたのデザインが物事を単純化するのではなく実際に物事をより複雑にするとき、あなたは過剰設計です。
詳細については、以下をご覧ください。
私の大まかな定義は、「要件仕様を満たすために必要ではない機能を提供する」です。
オーバーエンジニアリングとは、要件リストに従って実際に必要な数よりも多くのコンポーネントを使用してアプリケーションを設計および設計することを意味します。
過剰なエンジニアリングと、要件の変更に応じてアップグレードできる拡張可能なアプリケーションの作成との間には大きな違いがあります。例を思いつくことができれば、投稿を編集します。
オーバーエンジニアリングとは、必要以上の機能、品質、汎用性、拡張性、ドキュメント、またはその他の側面を備えた製品を作成することです。
もちろん、特定のプロジェクト以外の要件がある場合もあります。たとえば、将来同様のアプリケーションを実行することを予測している場合、コストに応じて、プロジェクト固有の要件に追加する拡張性に関する追加の要件がある可能性があります。
免責事項 #1: 私は全体像の BA です。私はコードを知りません。いつもこのサイトを読んでいます。これは私の最初の投稿です。
おもしろいことに、上司から、メンタリングを計画している新しいソフトウェア製品 (ターゲット市場の人事担当者) を設計しすぎたと言われたばかりです。だから私は用語を調べるためにここに来ました。
彼らは、既存のツールを再利用して、今すぐ販売できるものを手に入れたいと考えています。私たちが話した柔軟性の一部が許可されない場合、私は座って考えるしかありません.サインアップが少なくなり、保持率が低くなります. そして主に、サルが使用できる非常に視覚的な UI を備えています。
彼は、製品、特に UI を改善するための将来のフェーズを計画できると述べました。現在のお客様は、まだ行っていない「将来の改善」を待っています。彼らはそれを必要としていますが、本当に必要です。
私は辞任の過程にあるので、私は押し戻しませんでした。
しかし、私の定義は…………できる限り安価で、できる限り少ないことを確認し、それでもあなたが言うことにはまずまずです。その先はオーバーエンジニアリングです。
免責事項 #2: このサイトは、より構成可能なソフトウェアを実装する次の仕事に就くのに役立ちました。
あなたの質問に対する最良の答えは、この他の質問で見つけることができると思います
アジャイル プログラミングの優れた点は、適切に行えばオーバー エンジニアリングが難しいことです。