多くの問題を同じように解決する場合、私は心配する必要がありますか？

プログラミングゲームやパズルクリエイター/ゲームが大好きです。私は、これらの問題の多くを同じ方法でエンジニアリングし、最終的に私が本当に快適であるようにそれらをプログラムするために同様の手法を使用していることに気付きます。

簡単な洞察を与えるために、ノードがオブジェクトで表されるグラフを作成するのが好きです。これらのオブジェクトは、座標、位置、およびもちろん他の隣接オブジェクトへの参照などのデータを保持します。それらをすべてデータ構造に配置し、「ゲームループ」でこの情報を決定します。

これは簡単な例ですが、すべての状況で正確ではありません。それは私が本当に快適に感じる一つの方法です。これは悪いですか？

大丈夫です。

実用的なプログラミングのポイントは、多くの同様の開発に役立つソリューションを見つけることです。見つけました。

異なるためだけに異なるソリューションを作成することはできませんし、すべきではありません。ただし、ソリューションを毎回批判的に検討し、それらがまだ良いのか、それとも業界が進歩したのかを自問する必要があります。それに応じて調整する必要があります。

うまく機能する場合は、デザインパターンと呼びます。そうではないが、よくわからない場合は、金色のハンマーのアンチパターンです。

現実的には、日々の仕事ではかなり多くの同様の問題が提起される傾向があります。

これらの状況では、あなたが知っていることにこだわることは良いことです。誰かが非理想的なテクニックを上手に使用していることを理解していない何かを実装している人々から、悪い解決策の例を見てきました。

何かをよく知っている場合、必要に応じてそれを曲げることができ、実装は確実で効果的です。これらのことは、おそらくあなたが新しいテクニックを最初に試みたときは真実ではないでしょう。

しかし、裏側は、持っているのがハンマーだけであれば、すべてが釘のように見えるということです。あなたは、あなたが自分の選択肢を自分自身に気付かせるために、そしておそらくあなたがあなたのお気に入りをあまりにも遠くに押し出しているとき、物事をしているべきです。

おそらく、いくつかの緊急ではない/重要ではない変更を選択し、それらを使用して、代替ソリューションの速度を上げることができますか？

良い質問です。これも私を悩ませるものだと認めざるを得ません。

これはいつ大丈夫ですか？コードのパフォーマンス分析を行います-O（log n）またはO（n）またはO（n log n）にいることがわかり、そのような問題が既知のデータ構造にマッピング可能である場合、通常は問題ありません。

これがうまくいかないのはいつですか？時間または空間の複雑さがO（n ^ 2）またはそれより悪い場合、または定義による問題はNP完全です。これらの状況では、かなりのヒューリスティックを適用したり、他のドメインからの知識を適用したりする必要があります。

簡単な例：チップ設計では、最小限の電力で回路にゲートを配置する方法の選択はNP完全です。グラフだけでは十分ではありませんが、必需品です。追加の資料を読み、その多くは学際的であり、その知識をドメインに適用する必要があります。たとえば、遺伝的アルゴリズム（生物学101で定義されている遺伝的交差と突然変異を模倣するアルゴリズム）は、ハードウェアチップの設計に多くの用途があります。

必ずしもそうではありませんが、それがそれらを解決する良い方法であれば:)

通常、「ソリューション」に取り組むとき、私はこれらのことを順番に行います：

• シンプルさ、
• 再利用性、
• そして最後の パフォーマンスのみ。

パフォーマンスは重要ではありません：パフォーマンスを念頭に置いて設計しますが、あまり遠くにプッシュすることなく（したがって、同じフローでStringUtils.isEmptyなどのユーティリティメソッドを呼び出す必要がある場合は、心）。その後、パフォーマンスが必要な場合（ビジネスケースまたはユーザーエクスペリエンスの問題）、単純で再利用可能なアプローチとは異なるアプローチを採用します。実用的であること。

奇妙なことに、Cでコーディングするときは、Javaでコーディングするときよりもパフォーマンスを重視します。

問題が効率的な方法で解決されている限り、心配する必要はありません。

グラフは、意思決定や選択を表すゲームを設計するのに適した設計だと思います。おそらくこれは洗練され、より効率的になる可能性があり、これは他のドメインにとって最適なソリューションではない可能性があることに留意してください。

それが機能する場合、それは大丈夫です。

単一のテクニックに頼りすぎることを心配する場合は、解決策を実行不可能にするいくつかの解決された問題のバリエーションを考え出すための練習として試してください。変更を一般化して、通常のプロセスの適用スペースを定義できる場合の追加ポイント。

あなたが問題を解決するなら、それは良いことです。そして、それがより多くの問題を引き起こさないまで、それはどのようにでも問題ではありません。

あなたの目標が製品を生産することである場合、「開発者アート」は実際に正しい答えを持っています。そして、もしあなたの「工場」が満足する製品を生産すれば、それでクールです。

だが...

物事を行うための新しい（そして潜在的にはより良い）方法を学びたいなら、物事を変えなければなりません。これにより障害が発生しますが、実際には障害を通じてのみ学習します。そして、この新しい学習を通じて、さらに優れた魅力的なソフトウェアを作成できるようになります。

これは実際に神経学的研究によって裏付けられています。それであなたは行き​​ます。