『クラウドネイティブJavaの最適化 第2版』

付録B. パフォーマンス・アンチパターン・カタログ

この付録では、パフォーマンスのアンチパターンの簡単なカタログを紹介する。 このリストは決して網羅的なものではなく、まだ発見されていないものがたくさんあるに違いない。

ピカピカに気を取られる

レガシーなコードを掘り下げるよりも、新しいテクノロジーがどのように機能するかを探る方がエキサイティングな場合があるからだ。 また、新しいテクノロジーに付随するコードの方が、よりよく書かれたコードであり、メンテナンスが容易な場合もある。 これらの事実はどちらも、開発者をアプリケーションの新しいコンポーネントに目を向ける方向に向かわせる。

コメント例

「真相を究明する必要がある。

"私が紹介し、さらに読み取りを進めてきたのは、おそらくコンポーネントXだろう"

現実

• これは多くの場合、的を絞ったチューニングやアプリケーションの測定の努力というよりは、単なる闇雲な一撃に過ぎない。

• 開発者は新技術をまだ十分に理解しておらず、ドキュメントを調べるよりも、むしろいじくりまわすかもしれない。

• 新技術の場合、ネット上の事例は小規模なデータセットやサンプルデータセットであることが多く、企業規模へのスケーリングに関するグッドプラクティスについては議論されていない。

ディスカッション

このアンチパターンは、結成されたばかりのチームや経験の浅いチームによく見られる。 自分たち自身を証明したい、あるいはレガシーシステムと見なされるものに縛られるのを避けたいがために、彼らはしばしば新しくて「ホット」な新技術を擁護する。

したがって、論理的な潜在意識の結論としては、パフォーマンスの問題は、まず新しい技術を見てから取り組むべきだということになる。 結局のところ、正しく理解されていないのだから、新鮮な目で見ることが役に立つだろう？

決議

• ボトルネックの本当の位置を特定するために測定する。

• 新しい部品の周囲に十分な伐採を行う。

• 簡略化されたデモだけでなく、ベストプラクティスも見てみよう。

• チームが新技術を理解し、チーム全体のベストプラクティスレベルを確立する 。

単純なことに気を取られる

チームは、アプリケーション全体をプロファイリングし、客観的にシステムの痛点を探すのではなく、まずシステムの最も単純な部分（ ）をターゲットにする。 システムの中には、それを書いたオリジナルのウィザードだけが編集できる「専門家」とみなされる部分があるかもしれない。

コメント例

"理解できる部分から始めよう"

「ジョンがシステムのその部分を書いたが、彼は休暇中だ。パフォーマンスを見るには、彼が戻ってくるまで待とう。"

現実

• オリジナルの開発者は、その部分のチューニング方法（だけか）を理解している。

• さまざまなシステム・コンポーネントに関する知識の共有やペアプログラミングは行われておらず、単一の専門家が作成されている。

ディスカッション

もしアプリケーションが最近統合されたり、新技術と組み合わされたりした場合、チームは威圧感を感じたり、新しいシステムに関わりたくないと思うかもしれない。

このような状況下では、開発者は、慣れ親しんだシステムの部分のみをプロファイリングした方が安心だと感じるかもしれない。

特に注目すべきは、これら最初の2つのアンチパターンが、どちらも未知なるものへの反応によって引き起こされていることだ。Distracted by Shiny（ピカピカに気を取られる） ...