本当に、ほぼ保証に値します。初心者から 専門家 、アーキテクチャからASMに至るまで、そしてマシンのパフォーマンスから開発者のパフォーマンスまであらゆるものを最適化することで、あなたとあなたのチームがあなた自身の目標を短絡させている可能性は非常に高いです。

何？ 私？ 僕の チーム？

それは平準化するのにかなり重い告発です。説明させてください。

最適化は聖杯ではありませんが、取得するのは同じくらい難しい場合があります。チームの経験を自己破壊的なものから調和、充実感、バランス、そして最終的には最適化の1つに変えるのに役立つ、いくつかの簡単なヒント（および落とし穴の山）を共有したいと思います。

時期尚早の最適化とは何ですか？

時期尚早の最適化は、パフォーマンスを最適化しようとしています。

1. アルゴリズムを最初にコーディングするとき
2. ベンチマークが確認する前に、
3. プロファイリングの前に、わざわざ最適化することが理にかなっている場所を特定します
4. あなたのプロジェクトが現在指示しているよりも低いレベルで

今、私は楽観主義者、オプティマスです。

少なくとも、この記事を書いている間、私は楽観主義者のふりをするつもりです。あなたの側では、あなたの名前がOptimusであるふりをすることができるので、これはあなたにもっと直接話すでしょう。

需要の価格弾力性は何を測定しますか？

技術者として、あなたはおそらくそれがどうして可能性があるのか​​疑問に思うことがあるでしょう$yearそれでも、私たちのすべての進歩にもかかわらず、それはどういうわけか$taskの許容可能な基準ですとても面倒な時間がかかります。あなたは痩せたいです。効率的。驚くばかり。それらの求人情報が求めているロックスタープログラマーのような人ですが、リーダーチョップを持っています。したがって、チームがコードを書くときは、最初から正しく行うように勧めます（ここでは、「正しい」という用語が非常に相対的な用語であっても）。彼らはそれが賢いコーダーのやり方であり、後でリファクタリングに時間を無駄にする必要のない人々のやり方でもあることを知っています。

私はそのように感じる。完璧主義の力は私の中で時々強いです。あなたはあなたのチームに 少し 今時間を節約する たくさん 後で、誰もが自分のシェアを介して殴られたので「他の人が書いたShittyCode（彼らは何を考えていたのか？）」あなたが発音できない頭字語が好きだと知っているので、それは略してSCOPWWHWTTです。

また、チームのコードを自分自身や将来の誰かのためのものにしたくないことも知っています。

それでは、チームを正しい方向に導くために何ができるか見てみましょう。

何 最適化する：これは芸術であることへようこそ

まず第一に、私たちがプログラムの最適化について考えるとき、私たちはしばしば私たちが話しているとすぐに思い込みます パフォーマンス 。でも それ すでに見た目よりも曖昧になっているので（速度、メモリ使用量など）、そこで停止しましょう。

均等にしましょう もっと あいまいです！最初は。

私のcobwebbyの頭脳は、可能な限り秩序を作り出すのが好きなので、私がこれから言おうとしていることを考えるには、あらゆる楽観主義が必要です。 良いこと 。

（パフォーマンス）最適化の簡単なルールがあります。 しないでください 。これは厳密に従うのは非常に簡単に聞こえますが、誰もがそれに同意するわけではありません。私も完全には同意しません。一部の人々は、他の人々よりもゲートからより良いコードを書くだけです。うまくいけば、特定の人にとって、新しいプロジェクトで作成するコードの品質は、一般的に時間の経過とともに向上します。しかし、多くのプログラマーにとって、これは当てはまらないことを私は知っています。なぜなら、彼らが知るほど、彼らが時期尚早に最適化するように誘惑されるからです。

多くのプログラマーにとって…彼らが知っているほど、彼らは時期尚早に最適化するように誘惑されるでしょう。

したがって、この しないでください 正確な科学にすることはできませんが、パズルを解くという典型的な技術者の内なる衝動に対抗することだけを目的としています。結局のところ、これが多くのプログラマーをそもそもクラフトに引き付けるものです。わかりました。しかし、彼らに頼む それを保存 、誘惑に抵抗する。パズルを解くコンセントが必要な場合 たった今 、日曜紙の数独に手を出すか、メンサの本を手に取るか、行くことができます コードゴルフ いくつかの人為的な問題があります。ただし、適切な時間になるまでレポから除外してください。 ほとんどいつも これは、事前最適化よりも賢明な方法です。

この慣行は悪名高いので、人々は 時期尚早の最適化はすべての悪の根源です 。 （私はそれほど遠くまでは行きませんが、私は感情に同意します。）

デザインのあらゆるレベルで考えられる最も脳死の方法を選ぶべきだと言っているのではありません。もちろん違います。しかし、最も賢い見た目を選ぶ代わりに、 他の値を考慮する ：

1. 新入社員に説明するのが最も簡単
2. 最も経験豊富な開発者によるコードレビューに合格する可能性が最も高い
3. 最もメンテナンスしやすい
4. 書くのが最も速い
5. テストするのが最も簡単
6. 最もポータブル
7. 等

しかし、ここで問題が難しいことがわかります。それだけではありません 速度の最適化を回避する 、コードサイズ、メモリフットプリント、柔軟性、または将来性。それはバランスについてであり、あなたがしていることが実際にあなたの価値観や目標と一致しているかどうかについてです。完全に状況に応じたものであり、客観的に測定することさえ不可能な場合もあります。

それは芸術です。 （C.f. コンピュータプログラミングの芸術 。）

なぜこれが良いことなのですか？人生はこんな感じだから。散らかっています。私たちのプログラミング指向の頭脳は、混沌の中で秩序を作りたいと思うことがあるので、皮肉にも混沌を増やしてしまいます。それは誰かにあなたを愛するように強制しようとするパラドックスのようなものです。あなたがそれで成功したと思うなら、それはもはや愛ではありません。その間、あなたは人質取りの罪で起訴されており、おそらくこれまで以上に多くの愛が必要であり、この比喩は私が選ぶことができた中で最も厄介なものの1つでなければなりません。

とにかく、何かにぴったりのシステムを見つけたと思ったら、まあ…それが続く間、幻想を楽しんでください。大丈夫です、失敗は学ぶ素晴らしい機会です。

UXを念頭に置いてください

これらの潜在的な優先事項の中でユーザーエクスペリエンスがどのように適合するかを見てみましょう。結局のところ、何かがうまく機能することを望んでいることでさえ、あるレベルでは、UXについてです。

UIで作業している場合、コードが使用するフレームワークや言語に関係なく、ある程度の定型と繰り返しがあります。それを減らすことを試みることは、プログラマーの時間とコードの明快さの点で間違いなく価値があります。優先順位のバランスをとる技術を支援するために、いくつかの話を共有したいと思います。

node js express restapi認証

ある仕事で、私が働いていた会社は、意見の分かれた技術スタックに基づいたクローズドソースのエンタープライズシステムを使用していました。実際、それを販売したベンダーは、開発者にとって非常に苦痛だったため、スタックの意見に合わないUIのカスタマイズを行うことを拒否したとの意見がありました。私は彼らのスタックを使用したことがないので、これについて彼らを非難しませんが、実際には、これは「プログラマーにとっては良いこと、ユーザーにとっては悪いこと」のトレードオフでした。 そう システムのUIのこの部分を再実装するサードパーティのアドオンを作成することになった特定のコンテキストでの同僚にとっては面倒です。 （これは生産性を大幅に向上させました。私の同僚はそれを気に入っていました！10年以上後、 まだ そこにいる全員の時間と欲求不満を節約します。）

意見自体が問題だと言っているのではありません。私たちの場合、それが多すぎることが問題になりました。反例として、Ruby on Railsの大きな魅力の1つは、まさにそれです。 です 選択肢が多すぎるとめまいが起こりやすいフロントエンドエコシステムで、意見が分かれました。 （自分の意見がわかるまで意見を聞かせてください！）

対照的に、プロジェクトでUXをすべての王に戴冠させたいと思うかもしれません。価値のある目標ですが、2番目の話をさせてください。

上記のプロジェクトが成功してから数年後、同僚の1人が私に来て、ワンクリックで解決できるように、時々発生する特定の厄介な現実のシナリオを自動化してUXを最適化するように依頼しました。シナリオには多くの奇妙なエッジケースがあるため、誤検知や誤検知が発生しないアルゴリズムを設計することさえ可能かどうかを分析し始めました。それについて同僚と話をすればするほど、要件が単純に報われないことに気づきました。シナリオはたまにしか発生しませんでした（たとえば、月に1回）。現在、1人で解決するのに数分かかりました。でも もし バグなしで自動化に成功しました。同僚が節約した時間の観点から、必要な開発とメンテナンスの時間が報われるまでには何世紀もかかりました。私の中の人々を喜ばせる人は「いいえ」と言うのに苦労しましたが、私は会話を短くしなければなりませんでした。

したがって、ユーザーを支援するためにできることをコンピューターに実行させますが、それはまともな範囲に限られます。しかし、それがどの程度であるかをどうやって知るのですか？

私が採用したいアプローチは、UXのプロファイルを作成することです 開発者がコードをプロファイリングするように 。同じものを何度も何度もクリックまたは入力するのに最も時間を費やしているユーザーを見つけて、それらのインタラクションを最適化できるかどうかを確認します。あなたのコードは、彼らが入力する可能性が最も高いものについていくつかの知識に基づいた推測を行い、それを入力なしのデフォルトにすることができますか？特定の禁止されているコンテキスト（クリックしないEULA確認？）を除いて、これはユーザーの生産性と幸福に実際に違いをもたらす可能性があります。可能であれば、廊下のユーザビリティテストを行ってください。コンピュータが支援しやすいものとそうでないものを説明するのに苦労することもありますが、全体として、この値はユーザーにとって非常に重要である可能性があります。

時期尚早の最適化の回避：最適化する時期と方法

他のコンテキストの調査にもかかわらず、ここで、最適化を行っていると明示的に想定しましょう。 いくつかの側面 この記事の残りの部分の生のマシンのパフォーマンスの。私が提案するアプローチは、柔軟性などの他のターゲットにも適用されますが、各ターゲットには独自の落とし穴があります。重要な点は、時期尚早に最適化することです 何でも おそらく失敗します。

では、パフォーマンスの観点から、実際に従うべき最適化方法は何ですか？掘り下げてみましょう。

Windows10モバイルユニバーサルアプリ

これは草の根のイニシアチブではなく、トリプルです

TL; DRは次のとおりです。 上から下に作業します 。高レベルの最適化はプロジェクトの早い段階で行うことができ、低レベルの最適化は後で行う必要があります。 「時期尚早の最適化」というフレーズの意味のほとんどを理解するために必要なのはこれだけです。この順序で物事を行うと、チームの時間を無駄にし、逆効果になる可能性が高くなります。結局のところ、プロジェクト全体を最初からマシンコードで記述しているわけではありませんか？だから私たちのAAA 手口 この順序で最適化することです：

1. 建築
2. アルゴリズム
3. アセンブリ

一般的な通念では、少なくともパフォーマンスが関係する場合、アルゴリズムとデータ構造が最適化するのに最も効果的な場所であることがよくあります。ただし、アーキテクチャによって、使用できるアルゴリズムとデータ構造が決まる場合があることに注意してください。

私はかつて、財務トランザクションごとにSQLデータベースに複数回クエリを実行し、クライアント側で非常に基本的な計算を実行して、財務レポートを実行するソフトウェアを発見しました。中小企業がソフトウェアを使用するのに数か月しかかからなかったのは、比較的少量の財務データでさえ、まったく新しいデスクトップとかなり頑丈なサーバーで、レポートの生成時間がすでに数分に達したということです。かなり頻繁に使用する必要があったもの。最終的に、合計ロジックを含む単純なSQLステートメントを作成しました。つまり、すべての重複とネットワークのラウンドトリップを回避するために作業をサーバーに移動することでアーキテクチャを阻止しました。数年後のデータでも、私のバージョンでは同じ古いハードウェアでわずか数ミリ秒で同じレポート。

プロジェクトの後半でアーキテクチャの変更を実行できないため、プロジェクトのアーキテクチャに影響を与えない場合があります。上記の例で行ったように、開発者がそれを回避できる場合があります。しかし、プロジェクトの開始時にそのアーキテクチャに発言権がある場合は、今がそれを最適化するときです。

建築

プロジェクトでは、アーキテクチャは事後に変更するのに最も費用のかかる部分であるため、これは最初に最適化することが理にかなっている場所です。あなたのアプリが ダチョウを介してデータを配信する たとえば、悪いボトルネックをさらに悪化させないように、低頻度で高ペイロードのパケットに向けて構造化する必要があります。この場合、読み込みスピナーがそれをカットすることはないので、ユーザーを楽しませるためにテトリスの完全な実装を持っている方が良いでしょう。 （冗談はさておき：数年前、私は最初のLinuxディストリビューションであるCorel Linux 2.0をインストールしていましたが、長時間のインストールプロセスにそれだけが含まれていることを嬉しく思います。Windows95インストーラーのインフォマーシャル画面を何度も見て、覚えていました。当時は新鮮な空気の息吹でした。）

アーキテクチャの変更に費用がかかる例として、前述のSQLレポートがそもそも非常に拡張性が低い理由は、その歴史から明らかです。このアプリは、MS-DOSにルーツがあり、元々はマルチユーザーでさえなかった自家製のカスタムデータベースから、時間の経過とともに進化してきました。ベンダーが最終的にSQLに切り替えたとき、スキーマとレポートコードは1対1で移植されたようです。これにより、特定のレポートでSQLの利点を実際に利用してアーキテクチャの切り替えを完了できるようになるたびに、1,000％以上のパフォーマンスが大幅に向上し、アップデート全体に散りばめられました。私の当時の雇用主のようなロックインされたクライアントとのビジネスに適しており、最初の移行時にコーディング効率を明確に優先しようとしています。しかし、場合によっては、ハンマーがネジを回すのとほぼ同じくらい効果的にクライアントのニーズを満たすことができます。

アーキテクチャとは、プロジェクトをどの程度、どのように拡張できる必要があるかを予測することです。アーキテクチャは非常に高レベルであるため、特定のテクノロジーとドメインに焦点を絞らずに、「すべきこととすべきでないこと」を具体的に理解することは困難です。

私はそれをそれとは呼びませんが、他の誰もがそうします

ありがたいことに、インターネットには、これまでに夢見たほとんどすべての種類のアーキテクチャに関する収集された知恵が溢れています。アーキテクチャを最適化する時期が来たとわかったら、落とし穴を調査することは、あなたの素晴らしいビジョンを説明する流行語を理解することになります。誰かがあなたと同じように考え、試し、失敗し、繰り返し、ブログや本でそれについて公開した可能性があります。

流行語の識別は、検索するだけでは難しい場合があります。これは、FLDSMDFRと呼ばれるものについて、他の誰かがすでにSCOPWWHWTTという用語を作り出しており、解決しているのと同じ問題を説明していますが、使用する語彙がまったく異なるためです。開発者コミュニティが救いの手を差し伸べます！ StackExchangeまたはHashNodeに、できるだけ詳細な説明と、アーキテクチャのすべての流行語を追加してください。 そうではありません 、だから彼らはあなたが十分な予備調査をしたことを知っています。誰かが喜んであなたを啓発します。

その間、 いくつかの一般的なアドバイス 考えるのに良い食べ物かもしれません。

アルゴリズムとアセンブリ

助けとなるアーキテクチャを考えると、ここでチームのコーダーが時間の中で最もT-blingを取得します。時期尚早な最適化の基本的な回避はここでも当てはまりますが、プログラマーはこのレベルでいくつかの詳細を検討することをお勧めします。実装の詳細に関しては、考えることがたくさんあります。 最前線のコーダーと上級コーダーを対象としたコード最適化に関する別の記事を書きました 。

しかし、あなたとあなたのチームがパフォーマンス面で最適化されていないものを実装したら、本当にそれをそのままにしますか？ しないでください ？君は 決して 最適化しますか？

あなたが正しい。次のルールは、専門家のみのために、 しないでください まだ 。

ベンチマークの時間です！

コードは機能します。多分それはあなたがすでに 知っている 頻繁に実行されるコードであるため、最適化する必要があります。よくわからないか、O（n）アルゴリズムを使用していて、おそらく問題ないと考えているかもしれません。いずれにせよ、このアルゴリズムを最適化する価値があるとしたら、この時点での私の推奨事項は同じです。単純なベンチマークを実行します。

どうして？私のO（n³）アルゴリズムが他の何よりも悪くなる可能性がないことは明らかではありませんか？まあ、2つの理由で：

1. 現在達成されているかどうかに関係なく、パフォーマンス目標の客観的な尺度として、ベンチマークをテストスイートに追加できます。
2. 専門家でさえ、不注意で物事を遅くする可能性があります。当たり前のように思えても。 本当に 明らかです。

その2番目の点で私を信じていないのですか？

7,000ドルのハードウェアよりも1,400ドルのハードウェアからより良い結果を得る方法

StackOverflowで有名なJeffAtwood かつて指摘された 時々（通常、彼の意見では）、最適化に貴重なプログラマーの時間を費やすよりも、より良いハードウェアを購入する方が費用効果が高い場合があります。 OK、プロジェクトがこのシナリオに適合するという合理的に客観的な結論に達したとしましょう。さらに、最適化しようとしているのはコンパイル時間であると仮定しましょう。これは、作業中のSwiftプロジェクトであり、これが開発者の大きなボトルネックになっているためです。ハードウェアの買い物時間！

そこ対一人対私

あなたは何を買うべきですか？まあ、明らかに、円対円、より高価なハードウェアはより安価なハードウェアよりもパフォーマンスが良い傾向があります。明らかに、7,000ドルのMac Proは、ミッドレンジのMacMiniよりも速くソフトウェアをコンパイルする必要があります。

違う！

それが判明 それ 時々 より多くのコアはより効率的なコンパイルを意味します…そしてこの特定のケースでは、LinkedInはその逆がスタックに当てはまるという難しい方法を発見しました。

しかし、経営陣がさらに1つの間違いを犯しているのを見てきました。彼らは前後のベンチマークすらしていなかったし、ハードウェアのアップグレードによってソフトウェアの「感触」が速くならないことがわかりました。しかし、確実に知る方法はありませんでした。さらに、ボトルネックがどこにあるのかまだわからなかったため、問題に割り当てる時間とお金を使い果たして、パフォーマンスに不満を抱いていました。

OK、私はすでにベンチマークを行っています。実際に最適化できますか まだ ??

はい、必要だと判断したと仮定します。しかし、おそらくその決定は、他のアルゴリズムの多く/すべてが実装されるまで待つので、可動部分がどのように組み合わされ、プロファイリングを介して最も重要であるかを確認できます。これは、小さなアプリのアプリレベルの場合もあれば、1つのサブシステムにのみ適用される場合もあります。いずれにせよ、特定のアルゴリズムはアプリ全体にとって重要に見えるかもしれませんが、 専門家、特に専門家でさえ、これを誤診する傾向があります 。

混乱する前に考える

「私はあなたの人々について知りませんが…」

考えるべき最終的な手段として、誤った最適化のアイデアを、プロジェクトや会社自体、さらには経済のセクターなど、はるかに広い視野にどのように適用できるかを検討してください。

テクノロジーがその日を救うこと、そして私たちがそれを実現するヒーローになることができると考えたくなることはわかっています。

さらに、私たちがそれをしなければ、他の誰かがそうします。

しかし、最善の意図にもかかわらず、権力は腐敗することを忘れないでください。ここでは特定の記事にリンクしませんが、もしあなたがそれらに出くわしたことがなければ、経済を混乱させることのより広い影響と、これが最終的に誰に役立つかについて調べる価値があります。最適化を通じて世界を救おうとすることの副作用のいくつかに驚かれるかもしれません。

追記

オプティマス、何か気づきましたか？私があなたにオプティマスと呼んだのは、最初と最後でした。記事全体を通して、あなたはOptimusと呼ばれていませんでした。正直、忘れてしまいました。私はあなたをオプティマスと呼ばずに記事全体を書きました。最後に、私が戻ってテキスト全体にあなたの名前を振りかけるべきだと気付いたとき、私の中の小さな声が言った、 しないでください 。

基本を理解する

時期尚早の最適化とは何ですか？

最初のコーディング時に最適化しようとしています。パフォーマンスの最適化は、任意の時点で可能な最高レベルから行うのが最適です。グリーンフィールドプロジェクトの場合、アーキテクチャ段階。レガシープロジェクトの場合、コストのかかる推測ゲームをプレイするのではなく、ボトルネックを特定するための適切なプロファイリングの後。

なぜ時期尚早の最適化が悪いのですか？

（おそらく）パフォーマンスが最適化されたコードが、正確さ、明快さ、テスト容易性などよりも実際に最優先事項であると想定することは、隠れた落とし穴です。もう1つの落とし穴は、問題のコードが全体的なパフォーマンスに十分な影響を与え、最適化する価値があると想定していることです。時期尚早の最適化は両方に当てはまります。