プログラミングのためのデザインパターン

Question

私は適切なソフトウェアエンジニアリングの設計を学ぶための最善のアプローチを見つけようとしています。設計に先立ってプロジェクトを解剖し、最も有用なデザインパターンを実装する必要があります。私は "Gang Of Four"を読んだが、特定のソフトウェアに適切なデザインパターンを選ぶ確かな方法がないと感じている。

私は専門家がこれにどのようにアプローチしているのかよく分かりませんが、これは長年の経験から来ていると確信しています。しかし、何年ものプログラミングの後、まだデザインパターンの発見プロセスを見つけることはできません。

おかげで、 アル

Answer 1

正しいタイミングで正しいシナリオに正しいデザインパターンを選択して適用することは、常に課題です。デザインパターンは理論として学ばれることになっていますが、そのための味は、正しい技術決定がなされるべき時間と場所を特定する誰かの能力です。

学習者にとって、私の提案はパターンとその背後にある概念と同じくらい知っていることです。それらを与えられた理解可能な例でリフレッシュさせてください。次に、要件の明確化または機能設計フェーズ（そのアジャイルについてのグルーミング/計画セッション）または開発フェーズ（アジャイル：スプリント内）、またはコードレビューフェーズでコーディング設計を見て、一致するものを見つけるあなたが知っているパターンのマッピング。練習と経験によって、このスキルは改善され、後でエンジニアとしての試みが減ります。

また、設計パターンを適用する可能性が最も高い一般的な間違いや問題を検討してください。適切な設計パターンを適用して適切な技術的決定を前もって行うことができます（再発明せずに）。

私がSofwareエンジニアとして受け入れていた習慣は、D3（Design Driven Development）でした。完全またはJEDUF（Just-Enough-Design-Up-Front）が完全に完了するまで、効果的なコーディングが開始されていない（ええと、単語ではない!!）これは、開始する「効果的な」コーディングの直前で、ワークフローを定義し、適用可能なパターンなどを介して配線する方法を「正確に」知っていることを意味します（さらに、このアプローチによってコードレビュー時間が大幅に短縮されます）。

だから、私は言いたいのは、コンセプト精神の面でどれだけのパターンをカバーしているのか、正確な時間/場所が来たときに正しいパターンを選択するために正しい判断を下さなければならないか。

乾杯、D

Answer 2

あなたは読ん優れたソフトウェアデザインに興味がある場合： Domain Driven DesignまたはClean Architecture、または Test Driven Design。 GoFによって記述されたデザインパターンは、大きな文脈での一般的な問題を解決する方法ではなく、大きな絵のソフトウェアデザインを指すものではありません。

ソフトウェアデザインは石で書かれたものではなく、すべてコンテキストに依存することに注意してください。主な目的は、要求された（正しい）機能をユーザーに提供し、コードをテスト可能、保守可能にすること、および時間と予算のような特定の制約内で行うことです。

アジャイルな環境では、通常、細部まで細かく設計された設計者はいませんが、アジャイルプロセス中にソフトウェアのアーキテクチャが現れます。スクラム、カンバン、エクストリームプログラミングのようなアジャイル方法論に慣れてください。