architecture - オーバーエンジニアリングの具体的な症状

Question

私は最近、私の会社がメンテナンスを支援し、マイナーな機能を追加するために雇いたいと考えている 2 人の候補者に、私が書いた (社内の) アプリケーションを説明する立場にいることに気付きました。

これは私が書いた最初の「プロダクション」アプリケーションで、45,000 の LOC を持ち、「ソロ」開発にほぼ 2 年を費やしました。私はかなり若い (18 歳) で、会社を辞めた元開発者の代理として契約されながら、アプリケーションをゼロから作成しました。このサイズのアプリケーションを設計する経験がなかったので、共通のアーキテクチャおよび設計パターンを使用しようとしました。

今日、選択した ORM が既に実装している Unit Of Work パターンの代わりに、切断された変更追跡アーキテクチャを使用するなど、深刻なオーバーエンジニアリングを行ったことを知っています。「本当の」3層に行く必要はおそらくないでしょう。

両方の候補者は、関連するプラットフォームを使用した社内アプリケーション開発で 10 年以上のバックグラウンドを持っています。彼らの半分の年齢で、経験も浅い私は彼らの意見を尊重します。彼らにアプリケーションアーキテクチャを説明していたとき、次のようなコメントがありました。

ええ、そんなことをするために誰も私にお金を払ってくれません。私は物事を成し遂げなければなりません
フレームワークの機能に固執し、派手なライブラリ/テクノロジーを使用しないでください
フレームワークコードをラップしないでください。チームでは、とにかく全員が独自のラッパーコードを記述します。
.NET 3.5 を使用していますか? さて、私たちは2.0を使用しています。
その LINQ は私に何をもたらしますか? このすべてのクエリの構成と射影は複雑すぎるようです。

今、私は自問しています:
私は建築宇宙飛行士ですか? 自分が建築に行き過ぎていることをどのようにして知ることができますか? オーバーエンジニアリングの一般的な症状は何ですか?

score 130 · Accepted Answer

過剰設計の一般的な症状は何ですか？

あなたが持っていない問題を解決するコード。

score 28 · Accepted Answer

オーバーエンジニアリングの非常に強力な警告サインの1つは、すべてが非常に多くの間接参照を通過するため、具体的なドメインレベルの機能を実際に実装するコードを見つけるのが難しい場合です。ほとんどの関数が具体的な作業をほとんど行わず、他の仮想関数を呼び出すだけであることがわかった場合は、問題が発生している可能性があります。

score 22 · Accepted Answer

退屈

退屈は、過度に設計されたコードの良い前兆です。正直に言うと、最初の仕事を得たとき、私は十分に活用されていないと感じました。私はただ退屈していました。そして、退屈したときは、コードを書きました。単なるコードではありません -- CATHEDRALS OF CODE。

真剣に、私は自分のコードと抽象化を、金色の突き出た尖塔のある大きな塔、ガラスのオニキスのフライングバットレス、美しい幾何学的な網目模様で覆われたアーチ型のドームで支えられた素晴らしいボールトなどとして頭の中に描いていました。

パターンが一緒に機能しているのを見るのは本当に魅力的でしたが、振り返ってみると、私が残した不敬な混乱を完全に恥じています.

仕事であまり刺激のない時間を過ごすために、独自のフレームワークや DSL コードを書いているのであれば、やめてください。Wards Wikiを読んだり、オープンソースの本を書いたりすることに時間を費やすか、経営陣にもっと仕事を依頼したいだけかもしれません。

score 11 · Accepted Answer

あなたが建築宇宙飛行士であるかどうかについての質問について：あなたが多くの人々の前にあなたを置く危険性を知っているかどうか。あなたはあなたの牛の飼い主の邪魔をしたくありません、それは彼らの何人かが無愛想な古い泣き言になっているように聞こえます。

過剰設計は、システムの一部が過度に注目される結果となった優先順位付けの問題の結果です。したがって、過剰設計の最も明らかな症状は、注意力の欠如のために傷ついているシステムの他の部分の周りをすべて見ることができるということです。

（オーバーエンジニアリングは、システムを不適切な設計のリスクの増加にさらす傾向もあります。これは、オーバーエンジニアリングの複雑さの増加と、オーバーエンジニアリングの側面の決定に伴うエラーが発生しやすい推測の量のためですが、コメントが指摘しているように、それは自動的には続きません。）

score 10 · Accepted Answer

ほとんどの社内ビジネスアプリケーションの場合、ほとんどのコードはビジネス上の問題の実装に関係する必要があり、ビジネスに関係のない技術的な問題 (「切断された変更追跡アーキテクチャ」など) ではありません。現在利用可能なフレームワークはかなり成熟しており、ほとんどの一般的なユースケースをサポートしています。新しいテクノロジを発明している場合、または (ビジネスアプリケーション開発のコンテキストで) ラップするためだけに他の既存のフレームワークまたはライブラリをラップしている場合は、おそらく間違っています。理想的には、構築するアーキテクチャのすべての部分が、何らかのビジネス要件までさかのぼって追跡できる必要があります。複雑にしないでおく。

score 9 · Accepted Answer

アプリケーションについて寄せられたコメントのほとんどは、実際にはオーバーエンジニアリングに関するものではありません。なぜなら、オーバーエンジニアリングはテクノロジーに関するものではないからです。建築についてです。新しいテクノロジーは、妥当な時間内に習得して理解することができます。過度に設計されたアプリケーションを理解することは通常、はるかに困難であり、時には不可能ですらあります。これにより、ポイント 2、4、および 5 が無効になります。最初のポイントは実際には有効ではありません。なぜなら、アプリケーションをそのまま作成することで明らかに報酬を得ており、それが機能する場合はここで問題がないからです。

これは、アプリケーションが過度に設計されている傾向があるかどうかを調べるための私の「簡単なテスト」です。

「すべて」のラッパー:ラッパーは便利ですが、やりすぎるのは簡単です。本当にラップする必要があるものだけをラップしているかどうかを確認してください。（私は基本的に自分のラッパーを一度ラップしました。私が話していることは知っています;-)。）
車輪の再発明:古典。これは非常に一般的であり、すでに言及しました。必要に応じて何らかの機能を実装しましたか? あなたのフレームワークは、他の利用可能なライブラリではできないことを何をしますか?
オーバーエンジニアリングの「フィール」:これは最も重要なポイントですが、最も難しいポイントでもあります。コードを見て、どの部分が過度に複雑であるかを確認してください。それを実装するためのより簡単な方法があるかどうか、またなぜこの方法を選択しなかったかを自問してください。良い答えが得られなかった場合、この部分はおそらく過剰に設計されています。

これらは、私がアプリケーションで使用する簡単なヒントです。それらは、「オーバーエンジニアリング検出」のすべてであり、最終的なものであるとは限りません。

score 9 · Accepted Answer

同僚のコンピューターがあなたの頭を通り過ぎて飛んできた場合、彼らはあなたのばかげたフレームワークを使用しておかしなダイアログボックスを表示するのに 6 時間も費やしましたが、失敗しました。これはかなり具体的な症状です。

score 8 · Accepted Answer

YAGNI、DRY、KISSの使用を避けることは、過度に設計されたものを見るときに頭に浮かびます。部分的に完成しているように見える部分や、「こうなったら？それは別のポイントになります。OO 設計の優れた原則やSOLID 原則を無視することも注意が必要です。完璧なコードを書いたと思う場合、それは問題の別の兆候です。なんらかの方法で改善できないものを書く人は非常にまれだからです。

IMO、コードベースの一部には、メソッド、テスト、変数の命名規則など、特定の方法で物事を好む人々が関与する可能性があるため、一部の人々はあなたの仕事に過度に批判的である可能性があることに注意してください。仕方ないよ。さて、あなたが理解しなければならないのは、紛争や説得/影響などの状況で人々をどのように扱うかということです。そこでは、役立つツールがあります.

score 7 · Accepted Answer

アプリに固有の機能を提供するプラグイン

それに直面しましょう。プラグイン可能なアーキテクチャは、非常にセクシーで、書くのが楽しいだけです。ただし、これは、「本当にこの方法で行う必要があるのか」と自問する必要がある領域の1つです。

アプリケーションにアドホックな追加を行う必要がなく、サードパーティの拡張機能を誰かが作成することを期待せず、アプリケーションの範囲がかなり明確に定義されている場合は、プラグ可能なアーキテクチャは必要ありません。

アプリの固有の機能をサポートするプラグインを作成しないでください。ペイントプログラムを書いていたとしましょう。おそらく、複数の形式でファイルを保存するためのプラグインをサポートするでしょうが、プラグイン可能なアンドゥマネージャーやファイル参照ダイアログは必要ありません。

score 5 · Accepted Answer

あなたは建築の宇宙飛行士ではありません。LINQ は非常にシンプルで基本的で便利です。.NET 3.5 についても同様です。

同時に、あなたはチームの初心者であり、たとえ彼らがあなたの仕事を気に入っていたとしても、ある種の怒りを買うでしょう.

すべてを一粒の塩で取ってください。彼らの批判を受け入れてうなずき、後で彼らと一緒にビールを飲みましょう。

彼らがあなたにそれを変更するように頼んだ場合、あなたのコメントは「うわあ..私はそれが間違っていたことを知っていますが、それは機能し、変更するのは面倒です」.

score 3 · Accepted Answer

コードの予想される寿命にわたって作業を最小限に抑えるための作業を行ったかどうかを評価してみてください。これには、開発だけでなくメンテナンスも含まれます。

コードのライフサイクルでは、コードの寿命はアプリケーションの寿命と同じではないことに注意してください。最初に簡単なプロトタイプを作成し、ドメインをよりよく理解した後でリエンジニアリング/リファクタリングする方がよいでしょう。この状況では、ライフサイクルが非常に短いため、シンプルに保ちます。

さらに、アプリケーションが異なれば、必要なエンジニアリングの量も異なります。このアプリケーションが失敗した場合、コストがかかりますか？つまり、それは人工心臓用のコントローラーですか、それともスペースシャトルのナビゲーションロケット用のコントローラーですか？それとも退屈な10代の若者の連絡先リストですか？

score 2 · Accepted Answer

妥当な時間枠内にプロジェクトを実装しましたか？今は動いていますか？もしそうなら、おそらく少しリラックスすることができます。過剰なエンジニアリングに関する最悪の問題の1つは、実際に何か有用なことを行うことは決してないからです。

あなたが話した人たちにも良い提案があるかもしれませんが、それは彼らが言うことすべてを福音として受け入れる必要があるという意味ではありません。たとえば、新しいプロジェクトで最新バージョンの.NETを使用しても、心配する必要はありません。彼らは本当にそれについて不平を言っていますか？

score 2 · Accepted Answer

その半分は、彼らが知っている実証済みの真の蒸気エンジンに固執している老人（私は彼らのリーグに属しています）です. 残りの半分は真実ですが、実際には何も新しいことを伝えていません。

それ以外では、Jeff Sternal の答えはすばらしいものです。

score 0 · Accepted Answer

別の視点を提供したいのですが、この用語は取り消して、より適切な説明に置き換える必要があると思います。「オーバーエンジニアリング」として説明されているものの多くが正反対の性質を持っている場合、それは何よりもシンプルさと保守性と実用性に関するものであるべき「エンジニアリング」に汚名を着せます（エンジニアリングが多すぎる、またはそれを真剣に受け止めすぎているかのように）、最も複雑な解が得られるはずです)。たとえば、オーバーエンジニアリングと貧弱なテスト手順の間に相関関係があることはよくあることです (少なくとも私は、これら 2 つが密接に関連しているのをよく見てきました)。 ?

私は、システムの保守コストを削減したり、より健全なテスト手順を提案したりしようとしている人にこの用語を投げかけるために、SEに精通していないソフトウェアマネージャーや時折の恐竜をよく耳にしたという立場から来ています。安全基準。素人が、サウンドエンジニアリング、テスト、およびスプリントのようなスナップスナップスナップスナップのペースでコードを生成しないことに真剣に焦点を当てることは、「オーバーエンジニアリング」であると考えるのは簡単です.

「オーバーエンジニアリング」の真の匂いを真に認識している人はたくさんいますが、この用語は少なくとも間違いなく誤解を招くものです.

症状に関しては、すでに提供されている優れた症状以外に、目の前の仕事を適切に評価および再評価できる盲点です。プログラマーは、想像力の中で世界を構築し、夢中になり、そびえ立つ概念に没頭することができます。退屈で一般的な答えですが、実際の問題や優先事項が目の前にあることを認識できなくなる危険性があります。概念化が深すぎると、目の前に何があるかについて盲点を作り、問題を過度に複雑にし、現実と実際のユーザーエンドのニーズとの接点を失うことになります。私にとって、注意すべき最大の症状は心理学に関係しています。

制作を中心に展開するあらゆる種類の職業は、コンセプトに執着しすぎた結果、解決すべき実際の問題や差し迫った問題を見失うという基本的な傾向の影響を受けやすくなっています (例: 映画監督)。プログラミング全般において、これに対抗する方法は、単純さ、単純さ、実用性を優先し、何かをn度に概念化する前にコーディングすることです（アイデアに深く恋をする前に、再評価する時間を稼ぎます）。これらの理想を受け入れることは間違いではありませんが、私にとって重要なのは、自分の仕事を適切に評価することを妨げる盲点を作らないようにすることです. 過度に設計されたコードベースは、一晩でできるものではありません。

architecture - オーバーエンジニアリングの具体的な症状

17 に答える 17

Related

Reference