開発チームは、コンシューマーアプリのパフォーマンスの低下をどのように防ぐことができますか？

以前に遅いソフトウェアの原因を尋ねたとき、受け取ったいくつかの回答は、それが社会的および管理上の問題であることを示唆していました：

これは技術的な問題ではなく、マーケティングと管理の問題です。...結局のところ、製品マネージャーはユーザーが得ようとしているものの仕様を記述する責任があります。多くの問題が発生する可能性があります：プロダクトマネージャーが仕様にボタンレスポンスを配置できません...プログラマーはそれを補うことができません。— ボブ・マーフィー

人々は適切なサイズのアプリで作業します。動作すると、バグのようにパフォーマンスの問題が忍び込んでいきます。違いは-バグは「悪い」-彼らは「私を見つけて、私を直して」と叫ぶことです。パフォーマンスの問題はただそこにあり、悪化します。プログラマーは、「まあ、私のコードにパフォーマンスの問題はないだろう。むしろ、管理者は私に新しい/より大きい/速いマシンを購入する必要がある」と考えます。実際、開発者が定期的にパフォーマンスの問題を探しているだけの場合（実際には非常に簡単です）、単純にそれらを削除できます。— マイク・ダンレイビー

それで、これが社会的な問題である場合、顧客に遅いソフトウェアを出荷することを避けるために、組織はどのような社会的メカニズムを導入できますか？

正しく書かれた完全な要件により、バグとパフォーマンスの低さを区別するようなものはありません。パフォーマンスを非機能要件として指定するため、パフォーマンスの低下は他のバグと同様にバグになり、リリース前にQAによってキャッチされ、開発者によって解決されます。

社会的な問題はありますか？そうは思いません。主な問題は、要件が不完全であることです。フリーランサーとして何年も働いていた私は、特定のタスクが平均して最大N秒で実行されなければならないという非機能的な要件を見たことはありませんでした。マネージャー/顧客/利害関係者、またはパフォーマンスアセットについて何も気にしない場合、それを気にしなければならない人はまったく気にしないので、なぜ開発者としてそれを気にしますか？

パフォーマンスの低下に影響するもう1つの要因があります。開発者がパフォーマンスの高い高価なPCで作業しているという事実です。8 GBのRAM、ハイエンドSSD、最新のOSなどを搭載したクアッドコアPCで長年作業している場合、デュアルコアPC上のWindows XPでアプリケーションがどのように動作するか想像するのは非常に困難です。 512 MoのRAMと90％の空き容量があり、何年も最適化されていない古いハードディスクを搭載しています。残念ながら、一部の国では、最後のケースはアプリのほとんどの消費者に見られるケースです。開発者のPCと消費者のPCのギャップが大きいほど、開発者がアプリのパフォーマンスを管理するのが複雑になります。

問題（？）：

• 顧客（またはエンドユーザー）が文句を言うことはありません（十分）
• したがって、プロジェクト（/製品）マネージャーはそれを要件とは見なしません
• したがって、開発者はそれを修正する時間を得られません。

最初から始めて、顧客を教育する必要があります。しかし、高速で光沢のない電話の代わりにiPhoneを購入する場合、開発者はパフォーマンスではなく外見に時間を費やすのが正しいでしょう。組織は問題ではありません。

もちろん、とにかく役立つことがあります。自動化されたテストを待つのは煩わしいので、自動化されたテストがある場合、開発者はパフォーマンスの問題に関するフィードバックを常に得ており、（機能としてではなく技術的な問題として）解決する可能性が高くなります。

しかし、あなたはすべてをすることはできません。機能を最適化または追加し、お金を使う人が決定します。

しかし、いくつかの良いニュース：SaaS /クラウド/流行語アプリケーションがここで非常に役立つことに気づきました。ユーザーがいくつかの類似のWebアプリケーションから選択して、最初に「必須」機能の人為的なリストを作成する代わりにライブテストを行うと、応答性の影響がより迅速に得られるため、パフォーマンスがより注目されます。

悲しいことに、最大の問題は、あなたがすべてを行うことができないということです。出荷日があり、遅いことはわかっていますが、機能X、Y、Zを市場に出す必要があります。

あなたの心では、後で修正できますが、アプリは少なくとも動作します。

そのため、機能と美学を心配します（ユーザーが美学に集中することが多いためです）。次のリリースでは、パフォーマンスを修正します。

しかし、PMは機能のリストを提供するだけで、パフォーマンスを修正する時間はありません。

そして、悪循環が続きます。

開発者がより低速なハードウェアでテストする、パフォーマンスの目標を設定するなど、開発者に問題にもっと気を配らせる方法を見つける必要があることに、私は同意します。それで問題ありませんが、実際には、パフォーマンスチューニングに関しては-

人々は方法を知っている-そして彼らはしない

彼らはそう思うかもしれませんが、StackOverFlowとこのフォーラムでパフォーマンス関連の質問と回答をすべて調べてください。パフォーマンスに関する常識をほとんど示していない人がどれほどいるかが痛い。

それは、人々がで学ぶ必要がある、程度だけの話に何かありませんやってそれを。彼らがそのモードにいるのは、授業を受けているとき、または本やブログから新しいことを学んでいるときだけです。

したがって、この問題を解決するために考えられる唯一の方法は、プログラミングを教える人々を把握し、その方法を教えることです。

天国は知っています、私はこれらのフォーラムで試しました-

• 基本的な超単純な方法
• 43Xスピードアップ-やることをあなたのプロファイラで
• 吐き気を催すような詳細な理由

誰でもできます。彼らは実際にそれをする必要があります。

パフォーマンスを要件にします。

パフォーマンスコードの記述は困難です。スレッド、非同期イベント処理、キャッシュ、漸近的な複雑さなどの概念をしっかりと把握する必要があります。私が働いたプログラマーのグループから判断すると、特定のグループの約20〜40％は、パフォーマンスの考慮事項を当然のこととして日常業務に組み込むのに十分なほどこれらの概念を理解していません。

ただし、これらのプログラマーは明らかに会社にとって有用ですが、パフォーマンスが重要ではないと見なされるタスクに割り当てられるため、フレームを落とすことなくNetflixストリームを問題なく再生できるブルーレイプレーヤーになりますが、30〜60秒かかりますキューを表示するメニュー項目を開きます。

あなたがスタッフの20％を解雇し、より経験豊富な（そしてより高価な）開発者に置き換える余裕があるホットショットソフトウェア会社でない限り、それを修正する唯一の本当の方法は開発者トレーニングとバグレポートの提出です。他の会社でどうなっているのかわかりませんが、ここで開発者が修正する時間やビジネスの優先順位がないパフォーマンスの問題を見つけた場合、それについて独自のバグレポートを提出する権利があります。バックログのトップに到達するにはリリースが数回かかる場合がありますが、通常は最終的に対処されます。

パフォーマンスが必要な場合は、テストしてください。

それ以外の場合、Wallyは無限ループを記述して、「しばらく時間がかかります」という早い段階で放置することができます。彼は主張することができます。

ソフトウェア受け入れテストには、さまざまな動作パフォーマンス特性に対する詳細な受け入れテストが必要です。

これを行わない場合は、エンジニアリングしていない任意の製品にパフォーマンスを。

パフォーマンス（リソース消費など）は、サブシステムに割り当てられます。次に、サブシステムの受け入れテストでチェックできます。

次に、パフォーマンスを頻繁にテストすることができます。単体テストでも確認できます。

そのため、開発者はこれを受け入れ基準として持ち、それに合わせてアプローチを整理できます。

現在作業している場所では、パフォーマンスストレステストは、私たちが知っている顧客データセットの2倍です。製品の新しいバージョンが定期的に破損します。良いテスト。

私は90年代半ばに一度思い出し、何かを最適化しようとして少し時間を費やしていましたが、同僚が「これはペンティアムで実行されています。....それは目を見張るものでした。悲しいことに、それは氷山の一角に過ぎませんでしたが、「ペンティアム」の部分は時間とともに変化しましたが、私のキャリアを通じてその態度を聞いたことがあります。

平均的な開発者に注意を払う唯一の方法は、パフォーマンスの不足を顧客側のバグと見なすことです。アプリケーションと対象者に応じて、これは簡単な作業でも難しい作業でもあります（両方見ました）。視聴者がパフォーマンスの低下を気にしない場合、開発者は決して（迅速、良好、高速-2つを選択）しません。

しかし、プログラマーがキーを押してから応答するまでの3秒の遅れは許容できないことを認識するために、QAからの手紙を受け取るべきではありません。

すべきではないことに同意します。それ以上のものが必要です。得られた遅延がエンドユーザーに関連しているという証拠です。

コンテキストが提供されていないことを考えると、dev / QA環境での遅延は、ディスク/メモリ/ネットワークアクセスが遅いというローカルの問題が原因である可能性があります。その場合、QAと開発者は単にエンドユーザーにとって重要ではないものを修正するための努力を無駄にするだけです。

パフォーマンステストで開発者に依存することは、サイコロを転がして機能を選択してスピードアップするのと同じくらい生産的です。ああ、それはそれとほぼ同じくらい信頼性が高い-「開発者は一般に、アプリケーションのパフォーマンスの問題が実際にどこにあるのかについて恐ろしい直観を持っています」（Brian Goetz）。

• 私は、かつて彼らの優秀なマーケティング担当者とスマートプログラマーが顧客のパフォーマンスの懸念を処理するのに十分であると判断したラメ管理のプロジェクトに参加しました。素晴らしい教訓でした。リリースが拒否され、半年の努力がゴミ箱に移動し、会社は戦略的パートナーをほぼ失いました。最終的に、彼らは専門家（ベンチマーク、統計、UX、低レベルの最適化、そのようなものの専門家）を招き、専門家はその混乱を修正しました。

すべてのプログラマーが独自のQAを行って、そのような問題をすぐに確認する必要がありますか？

それが実行可能であるという事実は、それが行く方法であることを意味しません。むしろ反対です。私の経験では、これはプログラマの生産性を損なう最も信頼できる方法の1つでした。無限の会議とほぼ同じくらい良く、候補者にインタビューするよりも良い。

• 元テスターとして、開発とQAのアクティビティを組み合わせるのは問題ではないと思っていました。定期的な開発者テストと体系的なQAの違いはさほど重要ではないように見えました。dev / QA分離は、ソフトウェア業界の単なる伝統だと思いました。これはそうではないかなり難しい方法を学びました。分離は、焦点と生産性の問題であり、非常に深刻な問題であることが判明しました。

パフォーマンスの問題がある場合は、ベンチマークを提供して目標のパフォーマンスを設定してください。それを達成するために最善を尽くします。パフォーマンステストはそれほど得意ではありませんが、最適化については少し知っています。

99％の確率で問題がスコープクリープであることがわかると思います。たとえば、dvrを使用します。これは簡単だと思うかもしれませんが、TIVOまたは競合他社が好評の新機能を導入します。あなたが知っている次のことは、新しい機能がプレートにあります。既存の製品との互換性がある場合とない場合があり、時間がかかる既存の製品をやり直すことはありません。そのため、機能が妨害され、パフォーマンスが低下します。情報を取得するためにデータが存在することは確かですが、その情報を取得することを考えていなかった場合、取得するのは容易ではない可能性が高くなります。そのため、プログラムリストに近づくたびにその情報を作成する複雑なプロセスがあります。

気にしないように見える開発者を無視する...

多くの場合、コードを扱う開発者には、継続的にパフォーマンスを測定するツールがありません。

例：アプリの応答時間を測定できる場合（例：Webベースのアプリケーション、データベースのクエリなど）-「トップ10」の最悪を示す通知（電子メール、SMSなど）を現在受信していますか応答を実行しますか（または所定のしきい値を超えて）応答しますか？

多くの場合、多くの場合、開発者は「現実の」展開からこの情報を取得していないため、表示されない情報を非常に簡単に無視できます。

ただし、毎日/数時間で、画面 "x"の読み込みに13秒かかり、次のSQLクエリSELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN...を実行していることを示す電子メールを受け取った場合、開発者はすべて修正することができます（願っています）それ。

したがって、私はすべてのプログラマーがパフォーマンスを真剣に考えていると信じたいのですが、問題に対する可視性の欠如がしばしば犯人だと思います。

注：これは、開発者がアクセスを要求する（またはそのような機能を開発する）必要があり、管理者がそのようなツールを提供/資金提供する必要があるものだと思います。

実際にプログラマーのせいにすることができるより良い例を思いつくことができますか？Eclipseとは別に、それを行うプラグインがあることをすでに指摘しているコメント者がいます（新しいEclipseバージョンの最初のインストールは軽量化のように動作しますが、他のツールを追加すると遅くなります）、あなたの例はプログラマではなく、コードに関連していますが、環境に関連しています。

コンピュータ上でプログラムを単独で実行し、それが「高速」か「低速」かを判断する時代は終わりました。他の例は、環境によって異なります-現在のネットワークの混雑、バックエンドサーバーが過負荷になっているかどうか、ネットワークカードの設定が正しくないか、ケーブルに問題があるか、近くでそれを使用している他の人の数、または他の何百もの変数。例えば。ホスティングプロバイダーはサーバーギガビット接続に追加料金を請求しましたが、最終的にはすべてが10Mbポートの古代のファイアウォールデバイスを通過することを確認しました。これらの問題はあちこち移動し、見つけるのは困難です。

プログラマーができることはたくさんあります（帯域幅を最小限に抑え、応答性を改善し、進行状況を表示して速い印象を与えるUIトリック）。しかし、現実の世界に展開するときは、経験によってしか学ばないさまざまな状況があります（そして、自分の前で仮定がばらばらになるのを見ます）。

より良いソフトウェアにいくら支払うつもりですか？市場はより良いソフトウェアをどれだけ待ちますか？次のリリースに追加する必要のあるクラフはどれほど少ないでしょうか？

多くの妥協が行われている市場は、のどが渇いています。それが本当にがらくたであるなら、市場は製品に失敗する（または失敗する）。たぶん、現状維持に耐えられる十分な顧客がいるのでしょうか？

この問題に対する最も一般的な答えは、管理が最も難しいことでもあると思います。つまり、すべてのプログラマーは、何をするにしてもパフォーマンスに注意する必要があります。また、それはちょっとした警戒であることに気づきました。

プロジェクトの規模と対応するチームに応じて、専任のパフォーマンスプログラマーがいることには大きな価値があると考えています。

例として、プロジェクトチーム（約30人の開発者を含む）にパフォーマンスの最適化に専念する少なくとも2人のチームがあります。また、この特定のアプリは、Webサービス上だけでなく、さまざまなデータマッピングおよびアダプターコンポーネントを含むレガシーレイヤーに関しても相互運用性コンポーネントが多数存在するため、パフォーマンスの問題が非常に発生しやすくなりました。

直接体験することが重要です。開発者にコンパイルしてビルドするための高速なコンピューターを提供しますが、実際にアプリケーションを実行するための非常に遅い過負荷のコンピューター（一部のユーザーが実際に持っている場合があります）。（これは、クラウドまたはサーバーベースの開発環境で、機能ごとにVMまたはサーバーをパーティション分割することで実行できます。）バッテリーが半減した携帯電話を提供し、最初のモバイルアプリテストでのみ使用することを要求します。

開発者がパフォーマンスとバッテリ寿命に関して顧客に共感する場合、彼らはパフォーマンスを優先リストの一番下に置くべき準偽の管理仕様と見なしません。（例：「ちょっと、それは時期尚早の最適化だと思った」と手遅れになるまで。）

ものの購入をやめて、出会ったオンラインレビューのパフォーマンスの低さについてコメントしてください。

デバイスがまだ販売されている場合、ソフトウェアは「十分な」時間とお金を投資することはできません。パフォーマンスに関する悪い評価が大幅に販売を減らす場合、ソフトウェアは「不十分」であり、修正が必要です。

消費財の生産者が関心を持つ唯一の測定基準は、ユニットあたりの売上と利益です。

パフォーマンスの最大化などについてプログラマーにもっと教えられるべきだということに同意します。

しかし、私が思うに、この解決策はプログラマに日常的に使用するためのほとんど死にかけているハードウェアを提供するものではない。ビジュアルスタジオが1日に2回クラッシュした場合、どれだけストレスがかかるでしょうか。それは、ものを作成するのにx秒、ソリューションを開くのにy秒、ウィンドウを変更するのにz秒かかりました。ハードウェアは安く、プログラマーの時間は高価なので、会社にとっても非常に費用対効果が高いとは思いません。

コードを処理する次の手はQA（テスト）チームであるため、パフォーマンスの重要性について彼らに教え、エンタープライズ標準として許容可能なパフォーマンス標準などの標準を持っている（まあ、完璧な世界では） 、パフォーマンス標準は仕様内にある必要がありますが、それはあまり起こりません）？（つまり、重要なアプリであれば、通常のエンタープライズee変更ページ/タブは即座に発生し、「保存更新はx秒で発生します」...）QAチームが実行するコンピューターは、一般的なユーザーコンピューターである必要があります。（386を与えることで腹を立てたくありませんが、たとえば8GBのRAMを搭載したクアッドコアを与えないでください）。パフォーマンスに腹を立てたら、プログラマーに気を遣わないでしょうか？

クライアント/プロジェクトマネージャーは、プログラマー/ QAチーム/開発者/会社のチームの担当者に、彼らが持っている最も低い典型的なハードウェアでプレゼンテーションを行わせる必要があると思います。（たとえば、会社で最も弱いコンピューター）。書き換える場合は、古いソフトウェアでxプロセスを実行する速度に関するデータを収集し、新しいソフトウェアでの速度と比較する必要があります（新しいソフトウェアには追加のビジネスプロセスが含まれる可能性があるため、遅くなる可能性がありますが、許容できるウィンドウがあるはずです）。

前にも言ったことがありますが、もう一度言います。これを処理する最良の方法の1つは、単に開発者に（比較的）最先端のハードウェアで作業させることだと思います。

典型的なプログラマーにとって、公式のパフォーマンスに関するほとんどの考慮事項は、単に「実行しようとするとうっとうしいですか？」に次ぐものです。彼らはそれが迷惑だと思う場合、彼らはそれを修正します（少なくとも試してみてください）。彼らがその実行方法に満足しているなら、あなたが得る最高のものは、修正しようとする中途半端な試みです。これは、問題を修正するのにはるかに費用がかかる前に、問題を早期に発見するのにも役立ちます。

QAがパフォーマンスを適切だと考えるために開発者が本当に信じていないルールを実施しなければならない場合、あなたが得る「修正」のほとんどがルールを回避する創造的な方法を得る可能性はかなり高いです。エンドユーザーの生活を改善する本当の修正ではありません。

同時に、私はこれを問題としてめったに見なかったことを付け加えるべきです。どちらかと言えば、開発者がパフォーマンスを向上させるためにあまりにも多くの時間を費やしているのを見たことがあります。