デザインパターンと効率のどちらがより重要ですか? なぜ？

昨日、GitHub
上のオープンソース PHP プロジェクトのリクエストをプルしました。まず、構成
で有効になっているかどうかを判断し、ロードするのではなくクラスをロードすることを決定するために、共通ライブラリ内の共通コア関数を変更しました。そして、メソッド内で構成が有効かどうかを N 回判断します
これでも効率の点で大きな違いが生じると思います

提出後、オーナーは私の出発点が効率であることを理解したと返信しました。 、しかし、この判断はクラスに任せるべきです
わかりました、この方が「きれい」かもしれないと思いましたが、この理由だけで効率が犠牲になる可能性がありますか?
その関数は、次の場合に少なくとも15回呼び出されます単一の要求ですが、これは私にとって本当に不合理です
私も議論するつもりはありません、結局のところ、これは他の人のプロジェクトですが、非常に混乱しています

自分のコードの品質については非常に良いと感じています最初の 2 つの PR はオーナーによって統合されました
前回閉鎖された理由と上記と同様のことは心配しないでください。

返信内容:

パフォーマンスの最適化には、明らかなパフォーマンスの問題がなくなるまで最適化を行わない、という格言があります。パフォーマンスの最適化はコードの切り離しと再利用性に影響を与えることが多いためです。

質問者の具体的な例については、私は具体的なコードを見ていないのでコメントしません。 記述したコードが少なすぎます。クリーンな設計における低結合の拡張性は、少しの効率よりもはるかに重要です。何かが間違っていると思ったら、すぐに最適化してください。「時期尚早の最適化は諸悪の根源」という言葉をご存知ですか?

ただの暴言: PHP はいつからこの実行効率を気にし始めたのでしょうか? デザインパターンは効率を上げるために作られたものではないでしょうか？ (デザインパターンとは、開発効率とプログラム実行効率を向上させるために、長年のプログラマーによってまとめられた一連のプログラミング手法です。この場合、 はプロジェクトの要件やプロジェクトの具体的な実装に応じて を変更する必要があります。 ) 効率がボトルネックでない場合は、設計パターンが重要です。 明らかに効率の問題は事前に対処する必要がありますが、あなたが言及した例の構成の問題については、私はあなたの意見に同意しません。
具体的な理由は言えませんが、メソッド内で config を呼び出して判断するのが正しいと思います。効率に大きな影響を与えることは不可能です。 おそらくパフォーマンス テストを行うことはほとんどないでしょう。
そのようなパフォーマンスの最適化は、パフォーマンス テストのレポートにはまったく表示されません。あなたの最適化は、人が体重を減らすために鼻毛を切るのと同じです。効果がないとは言えませんが、実際には無意味であり、価値がありません。それを払った代償。 デザインパターンの方が重要です
デザインパターンは経験のまとめです
多くの場合、必然的にデザインパターンに行き着きます
それが良くない場合は、理解していない、間違った使い方をしているだけです場所

そしてパフォーマンスには多くの問題がある 時間は想像の産物である
実際のシナリオから乖離したパフォーマンスには意味がない

そして投稿者の問題は、それが当然のことであると思われていることのようであり、事前に最適化されている

システムは設計パターンに従って構築されている
誰もがパフォーマンスを理解し最適化する能力を持っている
事前にローカルのパフォーマンスを最適化してシステムが構築されている
私さえも理解していない後で触りたい コード効率が優先され、99%の環境で動作効率が問題になりません。一般に、可読性と保守性は運用効率よりも優先されます。重大な問題がある場合にのみ、特定の 1% ～ 10% の部分を最適化する必要があります。