厳しい納期で設計パターンを実装できましたか？

厳しい締め切りで、誰がデザインパターンを実装する時間があるのか​​と思います。初めて正しく時間枠内に収めるには、作業とプログラミングのオーバーヘッドがはるかに多くなります。それには長期的な利点があることは知っていますが、クライアントが頭に座っていてプレッシャーが高まっているときに、設計パターンを正しく実装できましたか。

最初のバージョンがリリースされて、次のリリースに十分な時間があれば、デザインパターンを使用してコードの品質と管理性を向上させることはできないと思います。

初めて正しく時間枠内に収めるには、作業とプログラミングのオーバーヘッドがはるかに多くなります。

それは誤りです。

誰かがすでに設計パターンを熟考し、それを説明して文書化することの利点がなければ、2倍の困難になります。

デザインパターンは、すべての思考、疑問や決断を単純化します。

新しいものを発明する必要はありません。自分や他の人がすでに理解しているものを使うことができます。

デザインパターンを使用すると、より少ない思考が可能になります。それが本当に重要なポイントです。この質問には、ほんの少し誤った二分法が含まれています。デザインパターンを使用するか、パターンをまったく使用しないことをお勧めします。本当の選択は、確立されたパターンを使用するか、自家製のパターンを使用するかのどちらかです。設計が推奨アプローチよりも優れている場合もありますが、通常はそうではありません。すでにうまく解決されている問題を解決するすべての作業を行う必要があるのはなぜですか。あなた自身の半分焼きたてのバージョンはこれほど良いものになることはほとんどありません。

私の経験では、クイック＆ダーティーはオキシモロンです。デザインを省くことで節約できる時間は、ほとんど常に追加のデバッグによって消費されます。

正しいことを行うのに十分な時間を与えられない期限にコミットしないでください。最終的には技術的な負債を返済する必要があり、正常な設計に物事をリファクタリングする前に配置するコードが多いほど、難しくなります。つまり、さらに多くの作業とプログラミングのオーバーヘッドを意味します。

デザインパターンのリストは非常に長くなります（人は物に名前を付けるのが好きです）。「OK、ここでは_ here を使っています」ということを考えていなくても、誰かが付けたパターンだと思います。プログラムするほど、何かを行う方法についてのアイデアが増え、使用しているパターンについて心配する必要がなくなります。

最初のバージョンがリリースされて、次のリリースに十分な時間があれば、デザインパターンを使用してコードの品質と管理性を向上させることはできないと思います。

私も同じような状況を共有しています。アプリケーションのメンテナンスでは、設計パターンを価値のあるものにするために、広範なリファクタリングが必要になる場合があります。角を曲がったところに大きなダウンタイムがある場合は、問題を修正する時間があるまで延期するのが最善です。

特にクライアントが昨日製品を要求している場合。ソフトウェア品質の三角形は、それを認めるか、認識しているかに関係なく存在します。「最初から正しくする」には、多くの場合、適切な要件や低い範囲のクリープなど、多くの事前計画が必要です。これは、クライアントがプロジェクトの共有成功に積極的に参加する意思があることを意味します。

また、OO 101では、要件が完了するまでセクションを作成する必要があることに注意してください。その後、リファクタリングします。それ以外の場合は、ホイールを回転させるだけです。

最初から正しくすることは、より多くの作業とオーバーヘッドではありません。

それが壊れていない場合、それは修正されません。正しくないということは、必ずしも壊れているという意味ではありません。常に何か他のことをする必要があります。したがって、それをサポートするのにはるかに多くの時間を費やし、それを修正したり何か新しいものを作成したりできる時間が少なくなります。

それを正しく行うことは、それを間違って行うことよりも時間がかからないことだけではありません。それはあなたが任意の締め切りやマイルストーンに達していないように短期的に現れるかもしれません。しかし最終的には、すべてがほぼ同じ時間でまとめられます。しかし、最初のQAリリースの品質は、パンツビルドのシートの最初のQAリリースをはるかに上回ります。これにより、リリース前のやり直しが減ります。結局、それを正しく行うことは、単に結びつくだけでなく、毎回勝利します。

おそらく、設計パターンの実装に時間がかかる場合、使用しようとしているパターンは、解決しようとしている問題に適していません。新しいパターンを実装するための次のコードレビューで「ボーナスポイント」を得ることはありません。ポイントは、一般的な問題を解決する実証済みの方法をより簡単に特定できることです。デザインパターンは、人々がこれらの問題へのアプローチを共有し、共通の言葉でそれについて話すことができる方法です。

すでに設計パターンを使用している可能性が非常に高く、それらは一般的に繰り返されるアーキテクチャー概念の単なる正式な分類です。

建築の類推を使用すると、建物の特定の部分を「雨と熱を遮断する部分」と呼ぶ場合、建物に精通している人はその部分を「屋根」と呼ぶだけです。「雨と熱を遮断する部品」を実装するのとは対照的に、家に「屋根」を実装するのに私が見ることができる欠点はありません。

主なオーバーヘッドは、状況に応じて見たときに非常に抽象的であることが多いため、どのデザインパターンがどこに適合するかを理解することです。手続き型を書かない限り、ほぼ確実にFacade / Factoryを使用しています。私は、オブザーバー、ストラテジー、ファクトリーが頭から始めるのが最も簡単だと感じました。

他の人が指摘しているように、最初に正しくそれを取得することはもちろん最も安いです。しかし、どんなプログラミング構造も、パターンとアンチパターンのスペクトルのどこかにあることも指摘しておきます。あなたは秩序だった方法で何かを実装しているか、そうではありません。「goto」感染したコードはパターンに従っています。これは、潜在的に有害であると早期に認識されたものにすぎません。ただし、すべてのコードはコンパイルサイクルのある時点でジャンプと分岐に要約されることに注意してください。ジャンプには本質的に問題はありません。大規模なプロジェクトが理解しづらくなるだけです。

単純なユースケースでは取るに足らないパターンに惑わされがちです。より多くの柔軟性が必要になるとすぐに、ほとんどのもろいパターンはアンチパターンに退化します。したがって、私のルールは、私が理解できるコードのみを記述し、デバッグの妥当な機会を与えることです。賢いパターンを盲目的に適用することにした場合、それをデバッグするには、少なくともパターンコードと同じくらい賢い必要があります。したがって、重要なのは、問題に直接当てはまるパターンを分離して利用し、適切な抽象化レベルで問題に取り組み、コードのすべての行を理解してデバッグできるようにすることです。

ここで重要なのは、短期要件と長期要件の適切なバランスを取ることです。優れたコードをすばやく書くことは、よく理解されているパターンから始めることで確かに役立つ可能性があることを覚えておいてください。スパゲッティコードは、特に最初は速く見えるかもしれません。しかし、分解可能性、モジュール性などが非常に重要となる、より大きなプロジェクトではアンチパターンの制限がすぐにわかります。

私は穀物に反対していると言いますが、彼らは助けることができますが、あなたが説明する状況下ではほとんどの場合傷つきます。

それらはあなたがそれらに非常に精通している場合に役立ちます（効果的なすべての部品のテスト範囲が十分にある場合、またはこれはグリーンフィールドコーディングです）。

しかし、実際には、この質問をする場合は、次のいずれかを行います。A。パターンを物事の自然な方法として使用しないでください（もしあなたが質問したくないと思ったのなら、考えずにそれを行うだけです）またはB.コードは、割り当てられた量のパターンの実装と互換性がないため、パターンを使用することは単に非現実的です。

いいえ。問題にベストプラクティス（デザインパターン、MVC、whetever）を適用するには時間がかかるようで、私や他の開発者がデザインパターンをよく知らないというわけではありません。

これらの優れたプラクティスのいくつかは、急いでいる場合でも適用できますが、優れたシステムでは、設計に時間がかかります。