開発チームはコンシューマーアプリのパフォーマンスの低下をどのように防ぐことができますか？
以前に質問した 遅いソフトウェアの原因は何ですか？私が受け取ったいくつかの回答は、それが社会的および管理上の問題であると示唆しました：
これは技術的な問題ではなく、マーケティングと管理の問題です。最終的に、製品マネージャーは、ユーザーが取得するはずの仕様を作成する責任があります。多くのことがうまくいかない可能性があります：プロダクトマネージャーはボタンの応答を仕様に入れられません... QA担当者は仕様に対してテストという平凡な仕事をします...製品管理とQAスタッフが全員運転している場合、私たちプログラマーはそれを補うことができません。 — ボブマーフィー
人々は適切なサイズのアプリに取り組んでいます。それらが機能するにつれ、バグのようにパフォーマンスの問題が忍び寄ります。違いは-バグは「悪い」-「私を見つけて、私を直して」と叫びます。パフォーマンスの問題はただそこにあるだけで悪化します。プログラマーは、「まあ、私のコードにはパフォーマンスの問題はないだろう。むしろ、経営者は私に新しい/より大きく/より速いマシンを購入する必要がある」と考えます。実際、開発者が定期的にパフォーマンスの問題を探しているだけなら（ これは実際には非常に簡単です ）、単純に問題を解決することができます。 — Mike Dunlavey
それで、これが社会的な問題である場合、遅いソフトウェアを顧客に出荷することを避けるために、組織はどのような社会的メカニズムを導入することができますか？
正しく記述された完全な要件があれば、バグとパフォーマンスの低下の区別はありません。パフォーマンスを非機能要件として指定するため、パフォーマンスの低下は他のバグと同様にバグになり、リリース前にQAによって検出され、開発者によって解決されます。
社会問題はありますか？そうは思いません。主な問題は、要件が不完全であることです。長年フリーランサーとして働いていた私は、特定のタスクが最大で実行されなければならないという機能以外の要件を見た決して[〜＃〜] n [〜＃〜]秒の平均。マネージャー、顧客、利害関係者、または何もパフォーマンス資産を気にしない場合、なぜ私は開発者として、気にかけなければならない人々がまったく気にしないので、気にしないのですか？
パフォーマンスの低下に影響を与えるもう1つの要因があります。開発者がパフォーマンスの高い高価なPCで作業しているという事実です。 8 GBのRAM、ハイエンドSSD、最新のOSなどを備えたクアッドコアPCで何年も作業している場合、アプリケーションがWindowsでどのように実行されるかを想像するのは非常に困難ですXP 512 MoのデュアルコアPCでRAMおよび古いハードディスクが90％充填され、何年もの間最適化されていません。残念ながら、一部の国では、最後のケースが1つです。アプリのほとんどのコンシューマーに見られるように、開発者のPCとコンシューマーPCの間のギャップが大きいほど、開発者がアプリのパフォーマンスを処理することがより複雑になります。
問題（？）：
- 顧客（またはエンドユーザー）はそれについて不満を述べていません（十分）
- したがって、プロジェクト（/製品）マネージャーはそれを要件と見なしません
- したがって、開発者はそれを修正する時間がありません。
最初から始めて、顧客を教育する必要があります。しかし、高速で光沢のないスマートフォンの代わりにiPhoneを購入した場合、開発者はパフォーマンスではなく外観に時間を費やすのが正しいでしょう。組織は問題ではありません。
もちろん、とにかくいくつかのことが役立ちます。自動テストを待つのは面倒なので、自動テストがあると、開発者はパフォーマンスの問題について常にフィードバックを受け取り、（機能としてではなく技術的な問題として）解決する可能性が高くなります。
しかし、すべてを行うことはできません。それは最適化または機能を追加し、お金を使う人が決定します。
しかし、いくつかの良い知らせがあります。SaaS/クラウド/流行語アプリケーションがここで大いに役立つことに気づきました。人々がいくつかの類似したWebアプリケーションから選択してテストを開始すると、最初に「必要な」機能の人工的なリストを作成する代わりにliveを実行するのではなく、応答性の影響をより早く受けるため、パフォーマンスがより注目されます。
悲しいことに、最大の問題はあなたがすべてを行うことができないことです。出荷日があり、遅いことがわかっていますが、機能X、Y、Zを市場に出す必要があります。
あなたの心の中で、あなたは後で修正することができますが、アプリは少なくとも機能します。
したがって、機能性と美学について心配します（ユーザーは美学に集中することが多いため）。次のリリースでは、パフォーマンスを修正します。
しかし、PMは機能のリストを提供するだけで、パフォーマンスを修正する時間はありません。
そして悪循環が続く。
低速のハードウェアでテストを実行したり、パフォーマンスの目標を設定したりするなど、開発者に問題をもっと気にかける方法を見つける必要があると私は他の人に同意します。それで十分ですが、実際には、パフォーマンスの調整に関しては、
人々はノウハウを知っている-そして彼らは知らない
彼らは考えているかもしれませんが、StackOverFlowとこのフォーラムでパフォーマンス関連のすべての質問と回答を確認するだけです。パフォーマンスについて常識をほとんど示さない人がどれほどいるのかは、つらいことです。
それは単に話をするものではありません、人々はそれをすることによって学ぶ必要があります。彼らがそのモードにいるのは、クラスを受講しているとき、または本やブログから新しいことを学んでいるときだけです。
したがって、この問題を解決するために私が考えることができる唯一の方法は、プログラミングを教えて教え、それらを教える人々を手に入れることですどうやってするの。
天国は知っている、私はこれらのフォーラムで試しました-
誰でもできます。彼らは実際にそれを行う必要があるだけです。
パフォーマンスを要件にします。
パフォーマンスの高いコードを書くのは難しいです。スレッド化、非同期イベント処理、キャッシング、漸近的な複雑さなどの概念をしっかりと把握する必要があります。私が一緒に働いたプログラマーのグループから判断すると、特定のグループの約20〜40％は、パフォーマンスの考慮事項を当然のこととして日常業務に組み込むのに十分なほどこれらの概念を理解していません。
ただし、これらのプログラマーは会社にとって明らかに便利ですが、パフォーマンスクリティカルとは見なされないタスクに割り当てられるため、フレームを落とすことなくNetflixストリームを完璧に再生できるブルーレイプレーヤーになりますが、30〜60秒かかります。キューを表示するメニュー項目を開きます。
スタッフの20％を解雇して、経験豊富な（そしてより高価な）開発者に置き換えることができるホットショットソフトウェア会社でない限り、それを修正する唯一の実際の方法は、開発者のトレーニングとバグレポートの提出です。他の会社での状況はわかりませんが、ここで、開発者が修正する時間やビジネスの優先順位がないパフォーマンスの問題を見つけた場合は、完全に独自のバグレポートを提出する権利があります。バックログの先頭に到達するまでに2、3のリリースが必要になる場合がありますが、通常は最終的に対処されます。
パフォーマンスが要件である場合は、テストします。
それ以外の場合、Wallyは無限ループを記述して、「しばらく時間がかかる」ことを早期に残す可能性があります。彼は主張することができます。
ソフトウェア受け入れテストには、さまざまな動作パフォーマンス特性に関する詳細な受け入れテストが必要です。
これを行わない場合は、製品のエンジニアリングanyを行うわけではありません。
パフォーマンス（リソースの消費など）は、サブシステムに割り当てられます。次に、サブシステム受け入れテストでそれらをチェックできます。
次に、パフォーマンスを早期かつ頻繁にテストできます。単体テストでも確認できます。
したがって、開発者はそれを受け入れ基準として持ち、それに適合するようにアプローチを編成できます。
私が現在作業している場所では、パフォーマンスストレステストは、私たちが知っているどの顧客データセットよりも2倍大きいです。それは定期的に製品の新しいバージョンを壊します。良いテスト。
90年代半ばに一度覚えていて、何かを最適化するためにしばらく時間を費やしていて、同僚が私に言った、「これはペンティアムで実行されています。 ....それは目を見張るものでした。残念ながら、それは氷山の一角にすぎませんでした。「ペンティアム」の部分は時間とともに変化しましたが、私のキャリアを通じてその態度を聞いたことがあります。
平均的な開発者に注意を払う唯一の方法は、パフォーマンスの欠如を顧客側のバグと見なすことです。アプリケーションと対象者に応じて、これは簡単な作業か難しい作業のどちらかになります（私は両方を見ました）。聴衆がパフォーマンスの低下を気にしない場合、開発者は気にしないでしょう（すぐに、良い、速い-2つ選択してください）。
ただし、プログラマがキープレスと応答の間に3秒の遅延は許容できないことを認識させるために、QAからの手紙を受け取るべきではありません。
同意しないでください。それ以上のことをする必要があります：取得したラグがエンドユーザーに関連しているという証明。
コンテキストを指定しなかった場合、dev/QA環境での遅延は、ディスク/メモリ/ネットワークアクセスが遅いというローカルの問題が原因である可能性があります。その場合、QAと開発者は、エンドユーザーにとって重要ではないことを修正するための努力を無駄にするだけです。
パフォーマンステストで開発者に依存することは、高速化する機能を選択するためにサイコロを振るのとほぼ同じくらい生産的です。ああ、それはそれと同じくらい信頼できる-「開発者は一般に、アプリケーションのパフォーマンスの問題が実際にどこにあるかについて恐ろしい直感を持っている」（ Brian Goetz ） 。
- 私は、ラメ管理者がかつて彼らの優秀なマーケティング担当者とスマートプログラマーが顧客のパフォーマンスの懸念を処理するのに十分であると判断したプロジェクトに参加しました。それはなんと素晴らしい教訓でした。リリースが拒否され、半年かけてゴミ箱に入れられ、会社は戦略的パートナーをほとんど失いました。最終的に、彼らは専門家（ベンチマーク、統計、UX、低レベルの最適化などの専門家）を招待し、専門家が混乱を修正しました。
すべてのプログラマーが独自のQAを行って、そのような問題がすぐにわかるようにする必要がありますか？
それが実行可能であるという事実は、それが進むべき道であることを意味するものではありません。むしろ反対-私の経験では、これは プログラマの生産性を失う への最も信頼できる方法の1つでした。終わりのない会議とほぼ同じくらい優れており、候補者の面接よりも優れています。
- 元テスターとして、開発とQAアクティビティを組み合わせても問題にならないと思っていました。日常の開発テストと体系的なQAの違いはそれほど重要ではないようです。開発とQAの分離は、ソフトウェア業界の伝統にすぎないと思いました。これはそうではないというかなり難しい方法を学びました。分離は、焦点と生産性の問題であり、非常に深刻なものであることが判明しました。
パフォーマンスの問題がある場合は、 benchmark を指定して、ターゲットパフォーマンスを設定してください。私はパフォーマンステストはあまり得意ではありませんが、最適化については 少々 を知っています。
私は、問題の99％がスコープのクリープであることに気付くと思います。たとえばdvrを使用します。これは簡単だと思うかもしれませんが、TIVOまたは競合他社が好評の新機能を紹介します。あなたが新しい特徴を知っている次のことはプレートにあります。これは既存の製品と互換性がある場合とない場合があり、時間がかかる既存の製品をやり直すことはありません。そのため、機能が機能しなくなり、パフォーマンスが低下します。確かにデータは情報を取得するために存在しますが、その情報を取得することを考えていなかった場合、簡単に取得できない可能性が高くなります。そのため、プログラムリストに近づくたびにその情報を作成する複雑なプロセスがあります。
気にしていないように見える開発者を無視しています...
多くの場合、コードに取り組む開発者には、継続的にパフォーマンスを測定するツールがないと思います。
例えばアプリの応答時間を測定できる場合（例：Webベースのアプリケーション、またはデータベースへのクエリなど）-現在、パフォーマンスが最も悪いことを示す通知（メール、SMSなど）を受け取っていますか？ （または所定のしきい値を超えて）応答？
多くの場合、多くの場合、開発者は「実際の」デプロイメントからこの情報を取得していないため、表示されない情報を無視するのは非常に簡単です。
ただし、毎日/数時間画面「x」のロードに13秒かかり、次のSQLクエリSELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN...が実行されていることを示すメールが届いた場合は、開発者はそれをすべて修正することができます（うまくいけば）。
したがって、私はすべてのプログラマーdoがパフォーマンスを真剣に受けていると信じたいのですが、問題に対する可視性の欠如が原因であることが多いと思います。
注：これは、両方の開発者がアクセスを要求する（またはそのような機能を開発する）必要があり、経営陣がそのようなツールを提供/資金調達する必要があるものだと思います。
実際にプログラマーのせいにすることができるより良い例を思いつくことができますか？ Eclipseを除いて、1人のコメンターはプラグインがそれを実行することをすでに指摘しています（新しいEclipseの各バージョンの最初のインストールは軽量化のように実行されますが、他のツールを追加すると速度が低下し始めます）。コード関連だが環境関連。
コンピュータ上でプログラムを分離して実行し、それが「速い」か「遅い」かを判断する時代は終わりました。あなたが与える他の例は彼らの環境に依存します-現在のネットワークの混雑、バックエンドサーバーが過負荷であるかどうか、正しく設定されていないネットワークカード、欠陥のあるケーブル、あなたの近くでそれを使用している他の人々の数、または他の何百もの変数。例えば。私たちのホスティングプロバイダーはサーバーのギガビット接続に追加料金を請求しましたが、最終的にはすべてが10Mbポートを持つ古いファイアウォールデバイスを通過することを確認しました。これらの問題は変化し、見つけるのが困難です。
プログラマができることはたくさんあります（帯域幅の最小化、応答性を向上させ、進行状況を表示して高速な印象を与えるUIトリック）。しかし、現実の世界に展開すると、経験によってのみ学習するあらゆる種類の状況があります（そして、あなたの前であなたの仮定がばらばらになるのを見ます）。
あなたはより良いソフトウェアにいくら払っても構わないと思っていますか？市場はより良いソフトウェアをどれだけ待つだろうか？次のリリースにどれほどの残骸が追加されることを望みますか？
それは多くの妥協がなされている市場のど真ん中です。それが本当にがらくたであるならば、市場は製品を失敗させるでしょう（またはすべきです）。多分現状に耐えられる顧客は十分いるのでしょうか？
この問題に対する最も一般的な答えは、管理するのが最も難しいことでもあると思います。つまり、すべてのプログラマーは、何をするにしてもパフォーマンスに注意する必要があります。また、それは少々警官のようなものです。
プロジェクトの規模と対応するチームにもよりますが、専用のパフォーマンスプログラマーがいることには大きな価値があると思います。
例として、プロジェクトチーム（約30人の開発者を含む）がパフォーマンスの最適化に専念する2人以上のチームを抱えているチームで作業しました。この特定のアプリは、Webサービスだけでなく、さまざまなデータマッピングやアダプターコンポーネントを備えたレガシーレイヤーに関しても、相互運用性コンポーネントが多数存在するため、パフォーマンスの問題が発生しやすかったです。
直接の経験が重要です。開発者にはコンパイルとビルドを行う高速なコンピューターを提供しますが、アプリを実行するには、非常に遅いオーバーロードコンピューター（ユーザーの一部が実際に持っている可能性があります）を使用します。 （これは、VMまたはサーバーを機能ごとに分割することにより、クラウド/サーバーベースの開発環境で実行できます。）バッテリーが半分切れている携帯電話を用意し、モバイルアプリの最初のテストの日はそれだけを使用するように要求します。
開発者がパフォーマンスとバッテリー寿命に関して顧客に共感するならば、彼らはパフォーマンスを優先リストの最後に置くためのいくつかの偽の管理仕様とは見なしません。 （次のように：「ねえ、それは時期尚早の最適化だと思った」遅すぎるまで。）
ものの購入をやめて、出くわしたオンラインレビューのパフォーマンスの低さについてコメントしてください。
デバイスがまだ販売されている場合、ソフトウェアは「十分な」ものであり、時間とお金をかけないでください。パフォーマンスに関する悪いレビューが売上を大幅に削減する場合、ソフトウェアは「十分でない」ため、修正が必要です。
消費財の生産者が関心を持つ唯一の指標は、売上高と単位あたりの利益です。
プログラマーはパフォーマンスの最大化などについてよりよく教えられるべきだということに同意します。
しかし、私が思うに、この解決策は、プログラマーに死にかけているハードウェアを日常的に使用できるようにするものではありません。ビジュアルスタジオが1日に2回クラッシュする場合、どれほどストレスがかかるでしょうか。ものを構築するのにx秒、ソリューションを開くのにy秒、ウィンドウを変更するのにz秒かかりました。ハードウェアが安く、プログラマーの時間も高いので、会社にとってもそれほど費用効率がよくなかったと思います。
次にコードを処理するのはQA（テスト）チームなので、パフォーマンスの重要性について教えたり、エンタープライズ標準として許容できるパフォーマンス標準などの標準を用意した方がよいでしょう（まあ、完璧な世界では） 、パフォーマンス標準は仕様に含まれている必要がありますが、それほど頻繁には発生しません）？ （つまり、通常の企業のeeを変更するページ/タブは即座に発生し、「更新の保存はx秒で発生する」、それが重要なアプリであれば...）。 QAチームが実行するコンピューターは、一般的なユーザーコンピューターである必要があります。 （私たちはそれらに386を与えることによって彼らを怒らせたくはありませんが、例えば8GBのRAMを持つクアッドコアを与えないでください）。彼らがパフォーマンスに十分腹を立てているならば、彼らはプログラマーに発散しないでしょうか？
クライアント/プロジェクトマネージャーは、プログラマ/ qaチーム/開発者/会社のチームの担当者に、彼らが持っている最も低い典型的なハードウェアでプレゼンテーションを行うように強制する必要があると思います。 （たとえば、会社で最も弱いコンピュータ）。書き換える場合、古いソフトウェアでxプロセスを実行する速度に関するデータを収集し、新しいソフトウェアでの速度と比較する必要があります（新しいソフトウェアには追加のビジネスプロセスが含まれる可能性があるため、速度が遅くなる可能性がありますが、許容できるウィンドウがあるはずです）。