私は開発者の立場から出てきたチームリーダー/機能アーキテクトであるため、コーディングの経験があり、現在進化している多くのことは、そもそも私が実装したものです。要点: リファクタリング (および懐かしさ) のためにいくつかのコードをレビューします。ベンチマークを実行した後、一般的なモジュールのパフォーマンスが約 5% 向上したことがわかりました。
そこで、私は何人かの同僚 (および私が運営するチーム) に連絡を取り、自分の変更点を提示しました。「マイクロ最適化」の全体的な印象に驚きました。すべての最適化を見ると、はい、それらはミクロですが、全体像を見ると...
ここでの私の質問は次のとおりです。最適化が「マイクロ」と見なされなくなったのはいつですか?
最適化がマイクロであるかどうかは通常重要ではありません。重要なことは、それがあなたにお金の価値を与えるかどうかです。
パフォーマンスを5％向上させるために、丸2営業日を費やしたとのことです。当時は賢く過ごしましたか？アプリケーションの「最も遅い」部分を修正したものでしたか、それとも少なくともパフォーマンスの問題を修正するのが最も簡単なものでしたか？変更により、（以前は達成しなかった）パフォーマンス目標を達成しましたか？あなたの場合、5％のパフォーマンスはまったく重要ですか？通常、パフォーマンスを改善する必要があると判断した場合は、100％または1000％の増加が必要です。
コードの可読性や保守性を損なうことなく、最適化を実行できますか？
その上、それらの最適化は他にどのようなコストをもたらしましたか？どのくらいの回帰テストを実行する必要がありましたか？いくつの新しいバグを作成しましたか？
これは答えというよりは質問のように見えますが、これらは最適化を行うかどうかの決定を左右する種類の質問です。
個人的には、アルゴリズムの時間やスペースの複雑さを軽減する変更（たとえば、から）と、コードを高速化またはメモリ要件を削減しながら全体的な複雑さを同じに保つO(N^2)変更を区別します。O(N)私は後者をマイクロ最適化と呼んでいます。
ただし、これは正確な定義ですが、変更を維持する価値があるかどうかを判断するための唯一の基準ではないことに注意してください。特に速度とメモリの要件が懸念の主な原因ではありません。
最終的に、答えはプロジェクトによって異なります。組み込みデバイスで実行されているソフトウェアの場合、ルールはHadoopクラスターで実行されているものとは異なります。