これらはすべて、ネイティブコードではなく、管理されたガベージコレクションされた言語で記述されているためですか？
関係ありません。遅いコードはパフォーマンスが低下します。確かに、特定の言語は特定のクラスの問題をもたらし、他の問題を解決する場合があります。しかし、優れたプログラマーは、十分な時間を与えられれば回避策を見つけることができます。
これらのデバイス用のソフトウェアを作成したのは個々のプログラマーですか？
部分的に。多くの場合、少なくとも寄与因子である可能性が非常に高いです。これは、優秀なプログラマーの需要と供給が不足している業界の不幸な副作用です。また、さまざまなレベルの技術的能力の間の溝は非常に大きくなる可能性があります。そのため、特定のソフトウェアを実装することを任されたプログラマーが、それを機能させるためだけに祝福することがあるのは理にかなっています（ある種）。
これらのすべてのケースで、アプリ開発者はターゲットとするハードウェアプラットフォームとその機能を正確に把握していました。彼らはそれを考慮しませんでしたか？
部分的に。最初は、ソフトウェア開発中にさまざまなメーカーと並行して交渉されることが多いため、正確なハードウェアプラットフォームはおそらく不明です。実際、最初のリリース後に、基礎となるハードウェアに小さな（しかし必ずしも重要ではない）変更が行われる場合があります。ただし、一般的な機能が知られていることに同意します。
問題の一部は、ソフトウェアがおそらくハードウェア上で開発されておらず、エミュレータで行われていることです。これにより、エミュレータが100％正確であっても、実際のデバイスのパフォーマンスを考慮することは難しくなります。
もちろん、これはリリース前の適切なプロトタイプハードウェアでの不十分なテストを正当化するものではありません。そのせいは、おそらくdev / qaの制御外にあります。
「最適化はすべての悪の根源である」と繰り返し言っている人ですか？
いいえ。彼らがとにかく彼の言うことを聞かないのは確かです。それ以外の場合、彼はそれほど頻繁に引用符を付けられません（これは「時期尚早な最適化...」と思われます）。:-D
最適化に関して、2つの極端のいずれかを採用するプログラマが多すぎる可能性が高くなります。
- どちらかが完全に無視します。
- または、実際のパフォーマンス要件とは関係のない特徴点に取りつかれています。最終的な効果は、予算がなくなり、コードが難読化されすぎて、実際のパフォーマンスの問題を安全に最適化できないことです。
それらすべてのミリ秒が合計して数分になるまで、それは毎回「おお、それはちょうど100msだけです」という考え方でしたか？
おそらく。Sleep(100)切断された肢の出血を遅らせるために使用されるティッシュペーパーと同等のものとして使用されている場合は、明らかに問題が予想されます。ただし、問題はそれよりも微妙だと思います。
問題は、現代のコンピューティングハードウェア（組み込みデバイスを含む）は、人々が信用を与えるよりもはるかに速いということです。ほとんどの人は、「経験のある」プログラマーでさえ、コンピューターがどれだけ高速であるかを正しく理解していません。100msは非常に長い時間です。そして、そのように起こると、この「非常に長い時間」は2つの方法を削減します。
- 1つ目は、コンピューターが非常に迅速に行うことについてプログラマーが不必要に心配することです。（たまたま「1秒間に300回値を増やす」という懸念があったため、そもそもここにいました。）
- 2番目は、物事が非常に長い時間がかかる場合（コンピューティングタイムスケールで）、彼らが時々正当な懸念を示さないことです。そう：
- ネットワークまたはストレージデバイスと通信する際の待ち時間の影響を無視する場合;
- ブロックされ、別のスレッドを待機しているスレッドの影響を無視する場合。
- コンピュータが非常に高速に動作するため、開発者が問題を意識することなく、タスクを必要以上に頻繁に繰り返すことができることを忘れた場合
- ...このような見落としの組み合わせが発生すると、ルーチンの実行が予想外に非常に遅くなります（コンピューティングタイムスケールで）。数回繰り返すと、人間にも気付かれることさえありますが、何百もの相互接続されたものがすべて自分ですばやく実行されているため、ピン留めするのは難しいかもしれません。
そもそもこれらの製品を購入したのは私のせいですか？
はい、間違いなく。まあ、あなた個人ではなく一般消費者です。製品は機能チェックリストで販売（および購入）されます。より良いパフォーマンスを要求している消費者が少なすぎます。
私の要点を説明するために：前回携帯電話を購入したかったとき、店は店内で遊ぶためのデモモデルを提供することさえできませんでした。彼らが持っていたのは、スクリーンがどのように見えるかを示すためのステッカー付きのプラスチック製のシェルだけでした。パフォーマンスや使いやすさは言うまでもなく、そのような重量を感じることさえできません。私のポイントは、十分な人々がそのビジネスモデルに反対し、彼らの反対を表明するために彼らの財布で投票すれば、私たちは正しい方向への小さな一歩になるだろうということです。
しかし、そうではないので、そうではありません。そして、毎年、新しい携帯電話はより高速なハードウェアでより遅くなります。
（質問は聞かれません。）
- マーケティング担当者のせいですか？部分的に。リリース日が必要です。そして、日付が迫ってきたとき、「機能させる」と「高速にする」の選択は簡単です。
- 営業担当者のせいですか？部分的に。彼らはチェックリストにもっと機能が欲しい。機能リストを誇張し、パフォーマンスを無視します。彼らは（時には）非現実的な約束をします。
- マネージャーは責任がありますか？部分的に。経験の浅いマネージャーは多くの間違いを犯すかもしれませんが、非常に経験豊富なマネージャーでさえ、他の懸念に賛成してパフォーマンスの問題を解決するために時間を犠牲にするかもしれません。
- 仕様のせいですか？部分的に。何かが仕様から外されている場合、後でそれを「忘れる」のはずっと簡単です。そして、特に明記されていない場合、ターゲットは何ですか？（個人的には、チームが仕事に誇りを持っている場合、パフォーマンスに関係なく心配すると思いますが。）
- 教育のせいですか？多分。教育はおそらく常に後足になります。ソフトウェア開発を表面的に理解している初心者を急速に混乱させる「教育」に私は確かに不賛成です。ただし、理論に裏付けられ、学習文化を植え付ける教育は悪くありません。
- アップグレードのせいですか？部分的に。新しいソフトウェア、古いハードウェアは本当に魅力的な運命です。バージョンXがリリースされる前でも、X + 1は計画中です。新しいソフトウェアは互換性がありますが、古いハードウェアは十分高速ですか？テストされましたか？特定のパフォーマンス修正が新しいソフトウェアに組み込まれる可能性があります。これは、不適切なソフトウェアアップグレードを奨励します。
基本的に、私は多くの貢献要因があると信じています。そのため、残念ながら、それを修正する特効薬はありません。しかし、それはそれが運命と暗闇であることを意味しません。物事の改善に貢献する方法があります。
それでは、これらの製品のどの時点で問題が発生しましたか？
私見では、特定のポイントを特定することはできません。時間の経過とともに進化した多くの要因があります。
- Beanカウンター：コスト削減、市場のタイミング。しかし、それでもプレッシャーなしに達成した進歩を達成できたでしょうか？
- 業界の熟練した人々の高い需要と低い供給。プログラマーだけでなく、マネージャー、テスター、さらには営業担当者も。スキルと経験の欠如は間違いにつながります。しかし、それはまた学習にもつながります。
- 最先端のテクノロジー。技術が成熟するまで、予想外の方法で定期的に噛みつきます。しかし、それでもまた、そもそも多くの利点がありました。
- 複合合併症。時間が経つにつれて、業界は進化してきました。ツール、テクノロジー、レイヤー、テクニック、抽象化、ハードウェア、言語、バリエーション、オプションの追加。これにより、現代のシステムを「完全に」理解することはやや不可能になります。ただし、結果としてはるかに短い時間でより多くのことを行うこともできます。
プログラマーとして、私たち自身の顧客にこの痛みを与えないようにするために私たちは何ができますか？
私はいくつかの提案（技術的および非技術的）を持っています。
- 可能な限りソファーで-あなた自身の製品を使用してください。ぎこちない、遅い、または不便なことを明らかにするために、直接体験するようなものはありません。ただし、「インサイダーの知識」による欠陥の回避を意識的に避ける必要があります。たとえば、バックドアPythonスクリプトを使用して連絡先を同期するのに問題がない場合は、「製品」を使用していません。それは次のポイントをもたらします...
- ユーザーの声に耳を傾けます（できれば最初の手ですが、少なくとも秒針はサポート経由で）。プログラマーは（一般に）隠れて、人間のやり取りを避けることを好みます。しかし、それはあなたの製品を使用するときに他の人が経験する問題を発見するのに役立ちません。たとえば、すべてのショートカットを知っており、それらを排他的に使用するため、メニューオプションが遅いことに気付かないかもしれません。マニュアルにすべてのショートカットが完全に記載されている場合でも、遅すぎるにもかかわらず、一部の人々は依然としてメニューを好むでしょう。
- 継続的にテクニックのスキルと知識を向上させるよう努めてください。学んだすべてを批判的に分析するスキルを身に付けます。知識を定期的に再評価してください。場合によっては、自分が知っていたと思ったことを忘れないようにしてください。それは育ちます...
- 一部のテクノロジー/テクニックは非常にトリッキーであり、微妙な誤解や誤った実装につながる可能性があります。共通の知識や利用可能なツールの進化による他の人は、賛成または反対になる可能性があります（シングルトンなど）。いくつかのトピックは非常に扱いにくいため、膨大な誤報を広める「hocus-pocus pundits」の集団を生み出しています。私の特定のバグは、マルチスレッドに関する誤った情報です。優れたマルチスレッド実装により、ユーザーエクスペリエンスが大幅に向上します。残念ながら、マルチスレッドに対する多くの誤った情報のアプローチは、パフォーマンスを大幅に低下させ、不安定なバグを増加させ、デッドロックのリスクを増加させ、デバッグを複雑化します。
- 所有権を得る。（真剣に、私は役員室のビンゴをしていません。）一部のチェックリスト項目よりも優先されるパフォーマンス機能について、マネージャー、製品所有者、営業担当者と交渉してください。より良い仕様を要求します。子供っぽくはありませんが、パフォーマンスについて人々に考えさせる質問をすることによって。
- 目の肥えた消費者である。機能は少ないが高速な電話を選択してください。（速くないCPU、より速くUI。）それについて次に自慢！より多くの消費者がパフォーマンスを要求し始めると、より多くのBeanカウンターがそれに対する予算を開始します。