デザインパターンは眉をひそめていますか？

私は20年間ビジネスに携わっているシニア開発者の1人と話し合いました。彼は、彼が書いているブログでオンタリオ州でよく知られています。

奇妙なことは、彼が私に言ったことです。彼は、教科書から書かれており、現実の世界を説明していないため、作業するのが悪夢のようなコードがあると言いました。UI /データベース/データレイヤーに新しいフィールドを追加するには、2〜3時間かかりますが、彼のコードでは30分かかります。

もう1つのことは、ほとんどのプログラマーが設計パターンを理解しておらず、保守の観点からは良くないため、設計パターンを避けることです。

また、カナダのほとんどのWeb開発者は、データモデルを分離せずに、データレイヤークラスから継承することを好むという考えもあります。「モデルをデータ層から分離することは業界標準ではないでしょうか？」彼は時々言ったが、ここのほとんどの人はそれがあまりにも多くの仕事であるのでそれをしないことを好む。

ベストプラクティスを使用してコーディングしない理由は、メンテナンスの悪夢であり、従業員のほとんどがそれを理解していないためです（自分自身を除く）。時間。

Stack Overflowは、人々が業界標準に従うことを主に奨励していることを考えると、このような意見を聞くのはとても奇妙です。数日のうちに新しいフィールドや機能を絶えず排除せざるを得ないという問題は、十分に柔軟な固体パターンを推測することができないということですか？これは私がこれから理解していることの要点のようです。

これらの声明をどう思いますか？

これらは成功を見つけた人の言葉であり、彼が理解できないパターンの専門用語で何をすべきかを彼に伝えようとする人々を無視します。

設計パターンとベストプラクティスは同じものではありません。 一部の人々は自分がそうであると考え、自分が何をしているのかを知っている人々を駆り立てます。たとえ彼らが何をしているかの適切な名前を知らなくても。

デザインパターンは、名前を付ける前に存在していました。話しやすくするために名前を付けました。名前のあるパターンは、良いことではありません。それはそれを認識できるものにします。

この男はおそらく誰も聞いたことのないパターンを使用しているでしょう。あなたが彼に何かをする方法について話す必要があるまで、それは大丈夫です。彼はあなたと話す方法を学ばなければならないか、あなたは彼と話す方法を学ばなければならないでしょう。「正しい」人とは何の関係もありません。

あなたとあなたの友人が説明している種類の多くの設計パターンは、実際にはプログラミング言語の欠陥に対する単なる回避策です。より表現力豊かなプログラミング言語を使用すると、これらの設計パターンの必要性のほとんどがなくなります。

考えられる多くの使用シナリオに対応するには、優れた設計パターンが必要であるため、過剰に設計される傾向があります。過剰に設計されたコードにはコストがかかります。ソフトウェアシステム全体のコンテキスト内でコードを読んで、その機能を理解し、どのように機能するかを理解する必要があります。その結果、他のソフトウェア開発手法と同様に、手法を使用するコストに対して手法を評価し、メリットがコストを上回るかどうかを判断する必要があります。

他のすべての条件が同じであれば、コードが少ないほど常に優れています。 レイヤードアーキテクチャを使用して、文字通り複数のプロジェクトを3〜6回ホップして、興味深いコード、つまりオーバーヘッドを追加する以外の何かを実際に達成するコードを見つける必要がありました。

よく知られているソフトウェアパターンは、設計戦略を伝えるための共通の語彙を提供することになっています。残念ながら、多くのソフトウェア開発者は、プログラミングの問題に適切に適用するのに十分なほどソフトウェアパターンの語彙を理解していません。経験の浅い開発者は、これらのパターンを専門家の領域内にあると見なします。彼らは専門家として見られたいと思っているので、彼らは準備ができる前に、パターンを早く学び、適用しようとします。代わりに彼らが本当にすべきことは、最初にプログラミングの基礎を学ぶことに集中し、次に各パターンが解決する問題を解決しようとすることです。これを行うと、パターンを正しく理解して適用するためのはるかに良い立場になります。

Stackoverflow.SEおよびProgrammers.SEは、業界標準ではなく、SOLIDなどのベストプラクティスに従うことを主に推奨しています。信じられないかもしれませんが、事実上の業界標準はしばしば「泥の大玉」アーキテクチャです-真剣に。

しかし、あなたの質問に直接答えるには、設計パターンの問題は継承の問題と似ています。多くの平凡な開発者がそれらを使いすぎており、コードのオーバーエンジニアリングや保守が困難になるリスクがあります。しかし、これに対する答えは、設計パターン（または継承）の使用を完全に回避または禁止しないことです。答えは、これらのツールを意味のある状況でのみ使用することを学ぶことです。そして、これは「アジャイル」の動作から完全に独立しています。

1. デザインパターンは、アイデアを伝えるために使用される単なる名前です。私はしばしば、自分が名前を持っていることを後で見つけたことをしていることに気づきました。したがって、「非設計パターン方式」とは対照的な「設計パターン方式」はありません。

2. 設計パターンはガイドラインです。すべてとして、それぞれに長所と短所があります。重要なのは、パターンを学習してそれを適切な場所に適用するのではなく、パターンのアイデア、長所と短所を理解し、それを使用して問題の解決策のインスピレーションを得ることです。

3. 十分な理由がある場合、すべてのベストプラクティスとガイドラインは無視できます。有効な理由には、開発時間とアプリケーションからの期待が含まれます。たとえば、値をハードコーディングするのは悪いこと（愚かな例）を知っていますが、概念実証のために、コストよりも利点のほうが大きい場合があります（この場合は、主に開発時間）。ただし、このような決定が下されると、裏目に出て、ある時点でリファクタリングが必要になる場合があります。

スープに別のメタファーを追加するために、デザインパターンはMicrosoft OfficeヘルパーClippyです。「あなたは多くのものに対して同じことをしているようです。イテレータまたはビジターを提供することでそれを手助けできますか？」

これらのパターンの適切な説明は、以前に何度も行われたのと同じ方法で何かを行うことが有用な場合、最初に試すときにどんな間違いをするか、そしてそれらの間違いを避けるために見つかった一般的な方法を示します。そのため、設計パターンを読んで（またはメモリからレビューして）、作業を続行します。できないことは、Clippyとウィザードのみを使用することです。

経験の浅い人が間違って現実を考慮しないコードを書くことができるのは、設計パターンのリストがソフトウェアの問題を解決するためのすべての可能なアプローチの完全なリストであり、設計をリンクしてコードを設計しようとするときですそれが終了するまでパターン。野生で見られるもう1つの貧弱な戦術は、デザインパターンが「ベストプラクティス」であるという事実に基づいて、デザインパターンを実際には適さない状況に靴べらにすることです。いいえ、実際に解決する問題のクラスのベストプラクティスである場合とそうでない場合がありますが、解決に失敗した問題、または単純なソリューションがある場合に不必要な複雑さを導入するだけで解決する問題のベストプラクティスではありません。

もちろん、YAGNIに基づいてパターンを回避し、それが必要であることに気付き、通常の解決策を模索することも可能です。これは通常（常にではないが）最初から要件を実現するよりも悪いことであり、アジャイル開発においてさえ、完全に予測可能な要件が早期に発見されないとイライラする理由です。Javaが最初に汎用コンテナを不必要に複雑なものとして拒否し、後でそれらを元に戻したことに非常に面白がっていた唯一のC ++プログラマではありませんでした。

したがって、設計パターンを避けることを好むので、原則としてIterator を書くことを避けることは間違いなく間違いです。

UI /データベース/データレイヤーへの新しいフィールドの追加には2〜3時間かかりますが、彼のコードの場合は30分かかります。

あなたは本当にそれと議論することはできません：このメトリックによって、彼のデザインは他のものよりもはるかに優れています。彼がデザインパターンを避けたからかどうかは疑わしいが、デザインの際に正しい「現実世界」の問題を考えたためであり、経験を生かして教科書と高い理想。

そのため、フィールドを追加するためにコード内の多くの異なる点に触れる必要があるパターンは、「フィールドを簡単に追加できるようにする」というジョブにとって悪いパターンであり、それらのパターンは使用しません。階層化されたアーキテクチャはその点で実際に苦しむ可能性があり、デメリットを認識せずにデザインパターンを使用するのは間違っています。

それに対して、彼のデザインに新しいUIを書くのにどれくらい時間がかかりますか？プロジェクトが、フィールドを絶えず追加するのではなく、固定データモデル上で新しいUIを絶えず構築および展開するように彼に求めた場合、代わりにそのために設計したことを願っています。または同様に。しかし、そのすべての利点について、悲しいことに「アジャイルをしている」と言っても、別のトレードオフをする必要がないという意味ではありません！

設計パターンのメニューから選択すると、確かに最も重要な懸念事項について考えるのを止めることができます。しかし、ビジターを作成していることを認識し、それを文書化するか、「ビジター」と命名して、読者がすばやく取得できるようにすることは、何の邪魔にもなりません。適切に文書化するのではなく「これは訪問者です」と書くことは、シニア開発者が与える理由のためのひどい間違いです。プログラマーはそれを理解しません。訪問者が何であるかを知っているプログラマでさえ、「これは訪問者です」以上の情報が必要です。

あなたの同僚はNIH症候群に苦しんでいるようです（「ここでは発明されていません」）。

彼のコードが新しいフィールドの追加を容易にすることは完全にもっともらしいです：私はまた、他の人によって書かれたコードよりも自分のコードを更新するのがずっと速いです。しかし、この短期間の速度は、コードの保守性と移植性については何も言いません。私は彼に疑いの恩恵を与えます：既存のコードは、教科書に従わなかったり、間違った文脈で良いレシピに従った場合、実際に構造が悪いかもしれません。

設計パターンを避けることは本当に驚くべきことです。コーダーのコーディングと管理の私の過去30年間で、デザインパターンは、本能的に行われたものに言葉をかけるのに役立ち、意図、利点、不便、リスク、機会、および関連パターンをより迅速に理解するのに役立ちました。設計パターンは、複雑さをマスターするための真のアクセラレーターであることが証明されました！

• おそらくあなたの同僚は私たちのほとんどよりもはるかに頭がよく、生産性を著しく低下させることなくパターンを再発明するオーバーヘッドを支払う余裕がありますか？

• 「プログラマーは設計パターンを理解していない」という議論は、「自分が何をしているのか本当に説明できない」と聞こえます。または「自分のデザインについて議論したくない」。パターン化は全体的な理解を活用でき、上級の同僚が価値のある意見を共有できるようになると思います。しかし、あなたの先輩はそれを避けたいかもしれません。

階層化アプローチは、ほとんどのエンタープライズアプリケーションで他のアーキテクチャよりも優れていることが実証されています。ワールドクラスの主要なパッケージは、このアイデアを中心に構築されており、職人のアーキテクチャよりも桁違いに優れています。Martin Fowlerは、「エンタープライズアーキテクチャのパターン」に関する優れた本でこのアプローチを提示しています。ああ！申し訳ありませんが、実証済みのパターンに関するものです。あなたの同僚のNIHビューにはチャンスはありません;-)

多くの人が見逃している重要な洞察は、ソフトウェア設計はコンテキストに依存しているということです。ビジネス目標を達成するために存在し、目標が異なると異なるアプローチが必要になる場合があります。別の言い方をすれば、常に最高のデザインがあるにもかかわらず、常に最高のデザインはありません。

設計パターンは、標準的な問題に対する標準的な解決策です。ただし、問題がない場合、解決するのは労力の無駄です。

ウォーターフォールとアジャイルソフトウェアデザインの主な違いは、デザインの決定が行われるときです。ウォーターフォールでは、すべての要件を収集し、必要な設計パターンを特定してから、コーディングを開始します。アジャイルアーキテクチャでは、YAGNIの原則に従って、可能な限り選択について多くのことを知る最後の責任ある瞬間まで設計の決定を延期します。

つまり、ウォーターフォールでは、アジャイルで実際に必要なときに、必要性が予想される場合に設計パターンが適用される傾向があります。結果として、アジャイルプロジェクトは、予想されるすべてのニーズが実際にあるわけではないため、デザインパターンを適用する頻度が少なくなる傾向があります。

デザインパターンは、何をすべきかを規定しているため、実際にはデザインパターンとは呼ばれません。デザインパターンは、以前に行われたことを記述するため、デザインパターンです。一部の開発者または開発者は、特定のタスクを適切に達成するメソッドを設計し、同様の結果をもたらす同様の状況にそれを適用することができました。それだけです。多くのパターンには固有の長所と短所があり、技術とビジネスのニーズを評価して適用する適切なパターンを決定するのは教育を受けた開発者次第です。

その観点から、100％の1回限りのコードを書くことに真剣に取り組んでいない限り、ユースケースごとに概念や実装を使用できないのであれば、ほぼ確実に少なくともいくつかのデザインパターンを使用しています。「リポジトリ」や「作業単位」、さらには「MVC」のような派手で一般的な名前はないかもしれませんが、それによって「デザインパターンではない」わけではありません。

私は通常、GPSを使用した「ナビゲーション」の方法で考えるのが好きです。「ベストプラクティス」と「デザインパターン」を学習するときは、GPSナビゲーションルートを取ることを学びます。しかし、その地域を知っていれば、多くの場合、側道を運転すると過去の問題地域につながり、より速く、そして/またはより良くそこに着くことがわかります。これらのことに関してはほぼ同じです。経験により、ツールボックスを分解してショートカットを作成できます。

設計パターンを学習し、「ベストプラクティス」を学習するということは、背後にあるアイデアを理解し、特定の状況で選択できることを意味します。現実の状況は多くの場合、理論的な状況に比べて複雑であるため、多くの場合、教科書にはない制約や問題があります。クライアント/顧客は、製品を高速で、通常は安価にしたいと考えています。レガシーコードを使用する必要があります。サードパーティ製のツールを操作する必要がありますが、これはブラックボックスであり、効果がありません。あらゆる種類のもの。あなたの状況は特定です-ベストプラクティスとパターンはより一般的です。

SEのようなサイトの多くの人々が「ベストプラクティス」の回答と「デザインパターン」の回答を提供する主な理由の1つは、一般的かつ抽象化されたソリューションで回答しているため、ある種の問題を解決するための共通言語を提供するためです問題。そして、あなたが学ぶようにします。

そのため、アジャイル開発環境ではデザインパターンは嫌われません。ただし、開発がパターンに完全に適合するほど一般的かつ抽象的であることはめったになく、（経験のある）開発者はこれを知っています。

UI /データベース/データレイヤーへの新しいフィールドの追加には2〜3時間かかりますが、彼のコードの場合は30分かかります。

設計を「最適化」したい場合は、最適化しようとしているものを言う必要があります。

たとえば、レーシングバイクは最適化された車両であり、ボーイング747は最適化された車両でもありますが、さまざまな要件に合わせて最適化されています。

たとえば、「MVC」パターンのアイデアは、次のようなものに最適化されます。

• 同じモデルの異なるビュー（ビューはモデルに依存しません）
• 各レイヤーを個別に開発し（異なるチームなど）、統合前に個別にテスト（単体テスト）できます
• 等

彼のコードは他の何かのために最適化されているかもしれませんが、例えば：

• 最小限のコード行
• 1人がすべてのレイヤーに影響する変更を簡単に行うことができます（まったく異なるレイヤーがまったくないため）
• 等

パターンの説明は、問題の説明から始まり、どのパターンを解決することを目的としています。特定のパターンを使用しないことが「ベストプラクティス」であると彼が考える場合、（それが愚かなパターンではないと仮定し、時には有用なパターンであると仮定して）私は、そのパターンが主張する特定の問題がない/経験していないと思います解決するために、および/または彼は代わりに最適化しようとしている別の（より大きなまたはより緊急の、競合する）問題を抱えています。

デザインパターンはツールです。ツールと同様に、それらを使用する方法は2つあります。正しい方法と間違った方法です。私はあなたのドライバーと釘を与える、と一緒に木を2枚の参加をお願いする場合たとえば、あなたはする必要があり、ハンマーのために私に尋ねます。ハンマーは釘に使用され、ドライバーはネジに使用されます。

設計パターンは、特定の問題が発生した場合にのみ当てはまることが多いOne True Wayとして宣伝されることがよくあります。ジュニア開発者は、遊ぶ何か新しいものを見つけたとき、多くの場合子供のようです。彼らはそのデザインパターンをすべてに適用したいです。そして、パターンAが問題Bに適用され、パターンCが問題Dに適用されることを最終的に知る限り、本質的に何も問題はありません。それが存在するという理由だけでパターン。このパターンは、仕事に最適な（既知の）ツールであるため、使用します。

パターンの裏側はアンチパターンです。通常、実行時間またはメモリの点で、何度も悪いことが証明されているもの。ただし、パターンとアンチパターンの両方は、それらが存在する理由を理解していない開発者には役に立たない。開発者は、自分がやっていることは新しくて独創的であると考えるのが好きですが、ほとんどの場合、そうではありません。以前考えられていた可能性があります。それらの前の人々は経験のためにパターンを作成しました。

もちろん、若い開発者は古いことをする新しい方法を思いつくことが多いようです。ただし、あまりにも頻繁に、Dunning-Kruger効果のケースになります。開発者は、機能的なプログラムを作成するのに十分なことを知っていますが、自分の制限を理解していません。これを乗り越えるための唯一の方法は、ポジティブとネガティブの両方の経験によるものと思われます。彼らは自分自身が優れていると信じているためパターンを無視しますが、実際には10,000人の開発者がすでに特定の設計を使用しており、それが実際に悪いためにそれを破棄しました。

アジャイルは、進化するクライアントのニーズに迅速に適応することに関して、「物事をレスポンシブに処理する」ことを好みます。設計パターンを支持することも、軽視することもありません。パターンが最速で最も信頼性の高い方法である場合、開発者はそれを使用する必要があります。特定のパターンが単に「実行する」よりも時間がかかる場合は、パターンではないものを使用しても大丈夫です（もちろん、パフォーマンスが大幅に低下することはないと仮定します）。既知のパターンが見つからない場合は、クライアントに「いいえ」と伝えるよりも、独自のパターンを設計する方が優先されます。クライアント、特に支払いをするクライアントは通常正しいです。

パターンが道であると主張する人、またはパターンが存在の障害であると主張する人は誰でも間違っています。パターンは特定の状況に適用されるツールであり、状況に応じてさまざまな程度の成功を収めます。これは真実であり、MVCを選択したかどうか、データ転送オブジェクトを使用するかどうかなどに依存しません。重要なのは、合理的に短い時間枠でコードを実装することです。また、論理的なバグはほとんどありません。

通常、パターンは一貫性のあるデザインを可能にし、すべてのパターンを無視して100％オリジナルのアイデアを書くよりもパフォーマンスが向上しますが、すべてのパターンを避けることはできません。たとえば、y = x + 5の場合、x + 5の書き込みパターンを避けるために、本当にy = x +（5 * 3 + 15/3）/ 4と書きますか？いいえ、違います。y = x + 5と書き、次の問題に進みます。

人々は毎日パターンを使用していますが、それは大丈夫です。最も重要なのは、論理的に機能し、めったにクラッシュせず、ユーザーフレンドリーなコードを持つことです。それ以外に重要なことはありません。

「デザインパターンを回避する」ことはできません。ただし、システムの2つの部分を同じように設計することを避けて推測することはお勧めしません（これはお勧めできません。彼がおそらく意味するのは、「デザインパターンに準拠しているという理由だけで、デザインを盲目的に使用しないこと」です。あなたがしていることを考えることは間違いなく「ベストプラクティス」であり、教えるためにある大学が存在するべきです。悲しいことに、それは起こっていないようです。

設計パターンはアジャイルプラクティスとは相反しません。アジャイルプラクティスとは相反するものは、デザインパターンを使用するためにデザインパターンを使用することです。これは、「ファクトリーパターンを使用してこの問題をどのように解決するか」というラインに沿って考える新入生と学生の間の一般的なプラクティスです。

アジャイルとは、ジョブに最適なツールを選択することであり、選択したツールに合わせてジョブを形作ることではありません。
そして、それはすべての常識的な開発慣行に帰着するものです（もちろん、選択できるツールの選択は通常、企業標準、ライセンス制限（GPLや他のオープンソースツールなど）によって制限されているため、多くの場合妥協する必要があります特に再販用のソフトウェアを構築する場合は使用できません）、そのようなもの。

あなたの同僚/友人は、おそらくそれがデザインパターン自体を使用しているためではなく、別のデザインが優れている場合に特定のパターンの使用を示すために設計された人工的な構造であるため、コードに反対しました（多くの場合、主観的ですが、私は（特定のデザインパターンを強制的に使用すると、見苦しく、保守が難しく、非常に効率の悪いコードになる多くの例を見てきました。