プログラミングデザインパターンを把握できない
私は過去4年間JavaScriptを使用しています。私は自分の問題解決スキルに非常に自信があり、コードの品質が向上していることがわかります。私はコミュニティの最新情報を入手するよう努めており、現在ES2015とReact.jsを使用しています。ただ、プログラミングのデザインパターンが全然わからないような気がします。私はこれに関するリソースをどこで見つけるか知っています、そして私はそれについてすでに本を読みました。私は、プロジェクトの構造について意思決定をするのに、先輩に頼っていますが、それに取り組むのに問題はありません。
自分で何かを始める必要があるときはいつでも、次の2つの方法を探します。React.jsのような大きなライブラリ/フレームワークを使用している場合、コミュニティが行っていることをコピーする傾向があります。もっと小さいものを使用している場合は、モジュールパターンを使用します。この問題について理解が深まると、より良い決断を下せるようになると思いますが、今のところ完全に迷っています。
これに関する優れた教育を探すべきでしょうか？この件についてメンターが必要ですか？私はバカだけですか？これは本当に理解するのが難しいですか？
ソフトウェア設計パターンは、よく知られた問題のよく知られた解決策です。パターンを理解し、パターンがどのように機能するかを理解し、それぞれをソフトウェア設計に適用することが適切な場合。
ソフトウェア設計パターンを学習する方法は、一度に1つずつ学習することです。それは継続的な教育プロセスです。学習の足跡を減らしたい場合は、現在使用しているテクノロジーに直接関連するパターンを調べてください。
設計パターンについて知っておくべきいくつかの重要な事柄：
一部の設計パターンは、本質的にアーキテクチャーです。MVCおよびMVVMは、そのようなパターンの例です。このようなパターンは、それらが提供する組織的および構造的な利点が必要な場合に使用します。
一部のデザインパターンは、プログラミング言語の欠陥に対する回避策ですより表現力のあるプログラミング言語を使用する場合、これらのパターンは必要ありませんが、多くの場合、 tこの選択をします。 GoFパターン の大部分は このカテゴリ です。
ソフトウェアパターンを使用するのは、パターンが特に解決するように設計されている問題を解決しようとしている場合のみです。ステッチによってアプリケーションを作成している場合ソフトウェアパターンを一緒にすると、あなたはそれを間違っています。
存在するすべてのコンピューティング問題に対応する既存のソフトウェアパターンはありません。その場合、プログラミングは単なるパターンマッチングの練習になります。
一部のパターンは実際にはアンチパターンです。これらのパターンがもたらす追加の複雑さは、それらが提供する利点を上回ります。パターンごとに、これらのパターンのどれを避けるかを自分で決める必要があります。
皆さんの学習への取り組み方は少し異なり、あなたの一般的な取り組みが何であるかはわかりませんが、あなたが自分を「愚か」であるとラベル付けすることによって、あなたが自分自身を不幸にすることを信じています。
個人的には、多くの人が「成功した」ソフトウェアエンジニアと呼ぶものの観察から、デザイナーなどはすべて、彼らの学習に共通のテーマ「経験」を持っています。私はこれがあなたの「優れた教育」であると信じており、Amazonから大量の本を購入してそれらを読むこと（私の悪い習慣）よりも早く学ぶことができます。
したがって、たとえば、コマンドパターンのようなGOFパターンを使用して、選択した言語で実装します。それがあなたに与える利点と欠点を理解してください。これについては、デザインパターンに関するさまざまな書籍で説明されていますが、その知識を実際に適用し、そこから学ぶことをお勧めします。読書資料を割引しないでください。彼らは目的を持っていますが、ITの世界は教科書の演習ではありません。そうは言っても、それはITの世界に対する私の見解と見解であり、ソフトウェアエンジニアリングでのキャリアを開始したときの部分的な問題を表しています。また、非常に経験豊富なソフトウェア開発者でさえ、私が見る主要な問題は、焦り、彼らがしていることを楽しむことを忘れることです。だから、あなたの学習に時間をかけ、あなたの行動を実際に楽しむことを忘れないでください、さもなければ、なぜそれに時間を費やすのですか？
また、他人の実務経験を活かしてください。オープンソースソリューションには、良いものも悪いものもたくさんあり、そこから学ぶことができます。彼らがどのようにパターンを適用したかを見て、どのように異なる方法でそれに取り組むかを考えてください。
したがって、私の一般的なアドバイスは、アプローチが間違っていると感じた場合は変更することです。自分が把握していないと感じている資料を学んでいると感じている周りの人を見て、彼らが何をしているかを見て、または尋ねることさえします。
簡単に言えば、必要しないことです。それらなしでコードを書くことができます。マシューがコメントで述べたように、これはJavaScriptで特に当てはまり、言語は非常に柔軟で、プロジェクトは小さくなる傾向があります。しかし、4年間プログラミングをしているとしたら、繰り返しやぎこちない感じに遭遇していないとは思えません。設計パターンを再発見または欠落している領域です。
例：JavaScriptのイベントシステムは、多くの場合、目前のタスクには不十分です。 streamsイベントを結合または変換できるようになりたいと思ったことはありませんか？それとも、一連の出来事はそれ自体が一流の価値でしたか？ Mediatorおよび/またはObserverパターンが必要です。双方向のデータバインディングが必要ですか？同じ話。
もろいプロトタイプ階層は落胆しましたか？ Mixin/Trait/Subclass Factoryパターンを使用して救出してください。
非常に良い経験を積んだメンターを見つけてください。彼に質問し、コードを見て、コードレビューを送信し、彼とのコラボレーションを試みます。これは、コーディングスキルを向上させる最良の方法です。
追加：
好きな簡単なOSSプロジェクトにコラボレーションする
同じ問題を解決する方法が2つある場合は、常により単純な方法を選択してください
サイドプロジェクトを使用して、あらゆる種類の奇妙なエラーを自由に実行できるようにし、デザインパターンを "ハードな方法"（tm）で学習します。