9

これは主に、SQL に関する質問への回答が原因でした。UDF とサブクエリは、パフォーマンスのために意図的に省略されています。信頼性は当然のことではありませんが、コードは機能しなければなりません。

パフォーマンスは常に最優先ですか?非常に多くの回答が、パフォーマンスを最優先事項として提供されています。ユーザーは、コードをどれだけ迅速に変更できるかをより気にかけているようです。したがって、レポートの実行には 12 秒ではなく 15 秒かかります。私が解決策を提供しないことの言い訳をしない限り、彼らはそれを受け入れることができます.

明らかに、15 秒が 15 分に変わると問題がありますが、ユーザーは機能を望んでいます。彼らは、アプリケーションがビジネス ルールの変更や拡張要求に適応することを望んでいます。今から 6 か月後にコードを見て、簡単に識別できる 1 つの場所で変更を加えることができるようになりたいと考えています。別の関数やサブルーチン、または Udf を呼び出すと考えたために、誰かがコードをコピーして貼り付けたすべての場所を追跡する必要はありません。パフォーマンスを妨げます。

そうは言っても、私は保守性 (変更は避けられないことです。)、パフォーマンス (誰も砂時計をじっと見つめるのが好きではありません。)、再利用性 (どのコードを再度使用する必要があるかを判断するのは難しいです。) を注文します。

4

14 に答える 14

21

1. 保守性: コードが読めなければ、どんなに速くても意味がありません。そして、それは間違いなく再利用されません。

2. 再利用性:すべてのコードが再利用できるわけではありませんが、多くのコードは再利用できます。可能であれば、ぜひコードをシンプルにしてください。最も簡単なのは分割統治です。たとえば、何度も何度も使用する単純なコンポーネントを作成します。UI ウィジェットが最も一般的です。しかし、それはユーティリティと同じです。同様に、コードに構造/フレームワークを作成することも役立ちます。エラー検証コードなど

3. パフォーマンス:通常、ほとんどのコードは十分なパフォーマンスを発揮します。そうでない場合は、コード プロファイラーを使用します。多くの場合、ボトルネックは、可読性や再利用性を犠牲にして実行できた小さなコードの最適化よりもはるかに重要です。

于 2009-02-07T06:03:41.700 に答える
4

リストから 1 つを逃したと思います: 信頼性。

だから私の注文は

  • 信頼性と精度
  • 保守性
  • 再利用性
  • パフォーマンス

コードが正しくない場合、コードがどれほど高速であっても関係ありません。まず、コードが信頼できるものでなければなりません。

パフォーマンスはリストの一番下にあります。最適化が早すぎることはなく、パフォーマンスに問題がある場合にのみパフォーマンスを改善してください。

私はフライト シミュレーションを含むリアルタイム システムに取り組んできましたが、その環境でもパフォーマンスは考慮されますが、最優先事項ではありません1

私の経験では、私が書いたコードの 1% 未満しか最適化する必要がなかったと言えます。


1場合によっては、何かが十分に速くないことがあります。もちろん、設計やコーディングの際にはパフォーマンスが考慮されますが、リストの一番上にあるわけではありません。

于 2009-02-07T12:56:38.340 に答える
2

編集済み 2010-03-02 : 質問はもともと開始されました:

みんなNASAで働いてるの?パフォーマンスは常に最優先ですか?非常に多くの答え...

いいえ、私たちのほとんどは NASA で働いていません。

いいえ: パフォーマンスよりも信頼性と保守性が優先されます。再利用性も良好です。

広い制限内では、パフォーマンスは重要ではありません。

于 2009-02-07T05:50:44.143 に答える
2

もちろん、嫌な答えは「場合による」です。

基幹業務アプリケーションの場合、関連するアクティビティの応答時間は、その実行頻度に反比例する必要があります。ユーザーが 1 時間に 4 ~ 5 回アクセスする必要がある機能であれば、その月末レポートを取得するよりも迅速な方がよいでしょう。

ある程度、あなたは自分の質問に答え、かなり正当な理由を提供したと思います。あなたが見逃しているのは信頼性だけです。NASA の類推はここで出てきます。NASA や金融機関のためにコードを書いているのであれば、堅牢で信頼できるものである必要があります...そしてそれが最優先になると思います。

于 2009-02-07T05:51:02.910 に答える
2

私はNASAの請負業者であり、レポートの実行やプロジェクトの追跡など、主に管理目的でソフトウェアを開発および保守しています。

私はそこで約 1 年半働いていますが、彼らの主な関心事は保守性と、新しい機能やモジュールをどれだけ早く展開できるかだと思います。

ギネスが質問で述べたように、ソフトウェアに異常な時間がかからない限り、彼らは気にしないようです。

彼らが持っているように見える他の主な懸念は、使いやすさです。アプリケーションは、簡単に使用できるものでなければなりません。

結論として、保守性、ユーザビリティ、そしてパフォーマンスが、NASA の内部レポートおよび追跡ツールに対する主な関心事のようです。

于 2009-02-07T08:00:10.903 に答える
2

プロジェクトに応じてこれらの優先順位を再調整できる必要があり、難しいのは、プロジェクト間またはコードの異なるセクション間でさえも切り替えたときに動作をすばやく変更することです。私は非常に異なるプロファイルを持つ 3 つのアプリケーションに取り組んでいます。

  1. 1つはリアルタイムであり、そのパフォーマンスが予測可能であることを確認するために多くの作業が行われますが(必ずしも超高速であるとは限りません)、変更は大きな問題ではありません.IETFがRFCを変更/廃止し、兆候がほとんどない場合にのみ大幅に変更されます.その。(とは言っても、私はその保守性のレベルを非常に誇りに思っています)。

    • 別のアプリでは、1 日分のデータを処理するのに 16 時間かかったことがあります。言うまでもなく、絶対的なパフォーマンスがすぐに最優先事項になりました。しかし、このアプリ内でも、バッチコードごとの「重要ではない」から、クライアントコードごと、タスクコードごと、ファイルコードごと、レコードコードごと、 -field-code を per-byte-code で「非常に重要」にします。

    • 最終的なアプリには多くのビジネス ロジックが含まれており、パフォーマンスは決して問題ではなく、保守性と俊敏性が重要であり、このアプリはすべてのファッショナブルな方法論から最も恩恵を受けています。 「文字列 1 + 文字列 2 + 文字列 3 + 文字列 4」と書くのは、それが最も読みやすく、パフォーマンスとは無関係であってもです。

于 2009-02-07T08:06:31.623 に答える
2

これは興味深い質問であり、その答えは非常に興味深いものです。優先度は実装によって異なります。ユーザーが保守性や再利用性のためにパフォーマンスを犠牲にしない例の 1 つを紹介したいと思います。はい、信頼性の要因があります - バグ/エラーがあるはずです。そのため、保守性、パフォーマンス、再利用性を比較すると.

私たちのクライアントの 1 つは、オンライン取引サイトを持っていました。ピーク負荷の下では、ミドルウェア レベルで平均的なトランザクションが完了するまでに約 14 ミリ秒かかります。その後しばらくして、アプリケーションのパフォーマンスが低下し (何らかの理由により)、トランザクションの平均時間が 24 ミリ秒に増加しました。通常の開発者として、10 ミリ秒は驚くほど重要ではないと考えるでしょう。しかし、ビジネスの観点から考えると、驚くべきことです。どのように?分析しましょう:

ピーク負荷の下でリソースが完全に使用され、14 ミリ秒で 100 のトランザクションを実行できたと仮定します。現在、パフォーマンスが低下しているため、トランザクションに 10 ミリ秒余分にかかり、71.42% 余分な時間がかかります。これは、100 トランザクションではなく 28.58 トランザクションしか処理できないことを意味します。これは、ビジネスにとって深刻な損失を意味します。

実際、アプリケーションのパフォーマンスの重要性に関する文献はたくさんあります。パフォーマンス、保守性、信頼性、可用性の要因をビジネス/ユーザーの観点から定量化する方法を説明している、非常に優れた本「Quantitative Approach to Computer Architecture」があります。

同じことがコンテキスト固有であるため、重要性の順序は指定しません。

于 2009-02-07T14:10:43.370 に答える
1

彼らは、別の関数、サブルーチン、または Udf を呼び出すとパフォーマンスが低下すると考えていました。

それは間違った考えです。

私が注文するのは、保守性、パフォーマンス、再利用性です。

場合によっては (通常は IMO) 再利用性保守性です。それは、「簡単に識別できる 1 つの場所で変更を加えることができ、誰もコードをコピーして貼り付けたすべての場所を追跡することができない」ものを再利用したためです。

于 2009-02-07T05:52:46.557 に答える
1

NASA でさえ、パフォーマンスは第一ではありません! NASA では、コードが正しく信頼できない場合、人々が死亡します。

さらに、私の経験では、パフォーマンスが価値がある場合でも、それはある程度までです。通常、超えることによる付加価値がほとんどまたはまったくないパフォーマンス レベルがあります。対照的に、コードの一部がどれほど信頼できるものであっても、正確性を向上させることには追加の価値があります。コードの一部が実際に期待どおりに動作しないことが多すぎます。

私にとっての順序は次のとおりです。

  • 保守性 : 簡単に変更できなければ、今は正しくても、長くは続かないでしょう。
  • 再利用性 : 再利​​用により生産性が向上し、コードが少ないほど一般的に信頼性が高くなります。
  • パフォーマンス: パフォーマンスが重要な場合もありますが、パフォーマンスが重要なアプリケーションであっても、パフォーマンスが重要でないコードがどれだけあるかに驚かれることでしょう。パフォーマンスの最適化は、ボトルネックに対してのみ重要です。
于 2009-02-07T08:25:39.040 に答える
1

タグ数に基づく結果は次のとおりです。

  • パフォーマンス - 952
  • 再利用性 (いくつかの関連タグ) - 43
  • 保守性 - 14

これはどういう意味ですか: パフォーマンスは重要である必要がありますか? パフォーマンスは難しいので、より多くの質問が求められます。パフォーマンスに関する質問は、このサイトで行うのがより具体的/適切ですか?

于 2009-02-10T16:14:00.420 に答える
0

NASAで働いています。しかし、私は (現時点ではとにかく) リアルタイム コードや、パフォーマンスが重要となるものを保守または開発していません。NASA で作成されたソフトウェアのほとんどは、おそらくそうではありません。私の時代に恐ろしいコードを見たので、信頼性と保守性、その後にパフォーマンス、そしてほとんどのアプリケーションの再利用性というジョナサンの答えにも行きます。

于 2009-02-07T06:18:06.053 に答える
0

私のお気に入りの引用の 1 つは SICP からのものです ...

「コンピュータ プログラムは、人間が読み取り、偶然にもコンピュータによって実行されるように設計されています。」

私は自分の仕事のこれらすべての側面を評価します。しかし、コードの可読性 (表現力という用語を使用する人もいます) と私が使用するコードは、私の重要性のリストのトップです。

ちょうど私の 2c、素敵な週末を!

于 2009-02-07T08:29:00.813 に答える