コーディングの優先順位:パフォーマンス、保守性、再利用性?

https://stackoverflow.com/questions/523222

22-08-2019
|

質問

これは主に SQL の質問に対する回答が原因で起こりました。UDF とサブクエリはパフォーマンス上の理由から意図的に省略されています。信頼性については当然のこととして考えるべきではないため含めませんでしたが、コードは機能する必要があります。

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

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

以上のことを踏まえて、私は次のように注文します。保守性 (変更は現実です。)、パフォーマンス (砂時計を見つめるのが好きな人はいません。)、再利用性 (どのコードを再度使用する必要があるかを判断するのが困難です。)。

解決

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

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

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

他のヒント

リストから 1 つを見逃していると思います:信頼性;

だから私の注文は

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

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

パフォーマンスはリストの一番下にあります。決して早すぎる最適化を行わず、パフォーマンスに問題がある場合にのみパフォーマンスを向上させてください。

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

私の経験では、これまでに最適化が必要になったのは、自分が書いたコードの 1% 未満だけだと思います。

¹ 時には、何かが十分に速くないこともあります。もちろん、設計やコーディングの際にはパフォーマンスが考慮されますが、それがリストの最上位にあるわけではありません。

吸盤答えは "それが依存"、もちろんです。

の基幹業務アプリケーションの場合、関与活動のための応答時間は、それが実行されます頻度に反比例する必要があります。それは、ユーザーが4または5回にアクセスする必要がある機能はなら時間も持っていたより良いもの月末の報告書を引っ張っよりもきびきびなります。

私が思うに、ある程度、あなたはあなた自身の質問に答え、それのために、かなり妥当な理由を提供してきました。あなたが見逃しているだけでは信頼性である - とthaのNASAのアナロジーの出番これは、あなたがNASAのためにコードを書いている場合、または金融機関のために、それは血まみれのウェルより良い堅牢性と信頼性を持っていた...と。私はそれが最優先だろうと考えています。

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

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

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

彼らが抱えているもう 1 つの主な懸念は、使いやすさです。アプリケーションは簡単で使いやすいものでなければなりません。

結論として、NASA の内部レポートおよび追跡ツールに対する主な関心事は、保守性、使いやすさ、そしてパフォーマンスであると思われます。

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

1 つはリアルタイムであり、そのパフォーマンスが予測可能であることを確認するために多くの作業が行われます (必ずしも超高速であるとは限りません)。ただし、変更は大きな問題ではありません。大幅に変更されるのは、IETF が RFC を変更または廃止した場合のみであり、その兆候はほとんどありません。その。(とはいえ、私はその保守性のレベルを非常に誇りに思っています)。
- 別のアプリでは、1 日分のデータを処理するのに 16 時間かかることもありました。言うまでもなく、絶対的なパフォーマンスがすぐに最優先事項になりました。しかし、このアプリ内でも、パフォーマンスの重視は、バッチコードごとの「重要ではない」から、クライアントコードごと、タスクコードごと、ファイルコードごと、レコードコードごと、「重要ではない」に至るまで、大幅に異なります。 -フィールドコードをバイトコードごとに「非常に重要」に変更。
- 最終的なアプリにはビジネスロジックの多くが含まれており、パフォーマンスは決して問題ではありません。重要なのは保守性と俊敏性です。このアプリは流行の方法論のすべてから最も恩恵を受けています。ただし、パフォーマンスのためのリファクタリングに数週間または数か月を費やしただけでは、非常に困難です。たとえそれが最も読みやすく、パフォーマンスが無関係であっても、「string1 + string2 + string3 + string4」と書く必要があります。

の編集2010-03-02 の：質問もともと始めます：

誰もがNASAのために動作しますか？パフォーマンスは常に最初に来ていますか？だから、多くの答え...

私たちの無大半はNASAのために動作しません。

いいえ：信頼性と保守性は先に、パフォーマンスの来ません。再利用性があまりにも良いです。

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

これは興味深い質問で、答えは十分に非常に興味深いです。優先順位は、実装に依存します。私は、ユーザーが保守性や再利用性のためにパフォーマンスを犠牲にしません例の一つを提示したいと思います。はい、信頼性の要因があります - どんなバグ/エラーがあるはずです。だから我々は、保守性、性能、再利用性を比較したときます。

私たちのクライアントの一つは、オンライン取引サイトを持っていました。ピーク時の負荷の下での平均トランザクションは、ミドルウェア・レベルで完了するために、14ミリ秒の周りにいくつかの場所を取るだろう。後者のいくつかの時間は、アプリケーションのパフォーマンスが（何らかの理由で）分解し、トランザクションの平均時間が24ミリ秒に増加しました。今、通常の開発者として、私たちは10ミリ秒はそれほど驚くほど重要ではないと思うだろう。私たちは、ビジネスの観点から考えるなら、それは憂慮すべきです。どうやって？私たちは分析できます：

ピーク負荷の下で、リソースが十分に活用されていると仮定して、我々は100件の取引を行うことができました14msとします。今、パフォーマンスの低下との取引は71.42パーセントの余分な時間が10msの余分を取ります。さて、これは我々が唯一の28.58取引の代わりに、100の取引サービスを提供することができますを意味します。これは、ビジネスに深刻な損失を意味します。

Infactは、アプリケーションのパフォーマンスの重要性に関する文献がたくさんあります。パフォーマンス、maintability、信頼性、avaliabilityの要因は、ビジネス/ユーザー観点で定量化することができる方法を説明し非常に素晴らしい著書「コンピュータ・アーキテクチャへの定量的アプローチ」がある。

私は同じような重要性の順序を指定しませんが、コンテキスト固有のものです。

彼らは
他の関数またはサブルーチンまたはUDFを呼び出すと、パフォーマンスが低下するだろうと思いました

それは間違っている考え方です。

私が注文します：保守性、パフォーマンス、再利用性
。

時々（通常はIMO）再利用性のの保守性である：それはだあなたは「1つの簡単に識別点で変更を行うことができます何かを再利用し、すべてのそれらの場所をコピーしたコードを貼り付けsoneone追いかけていないので、」ます。

NASA であっても、パフォーマンスが最優先ではありません。NASA では、コードが正しくなく信頼性がなければ、人が死にます。

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

私にとって、順序は次のようになります。

保守性:変更するのが簡単でなければ、たとえそれが今は正しくても、長く正しい状態を保つことはできません。
再利用性:再利用により生産性が向上し、一般に、コードが少ない場合は、コードが多い場合よりも信頼性が高くなります。
パフォーマンス:パフォーマンスが重要な場合もありますが、パフォーマンスが重要なアプリケーションであっても、パフォーマンスが重要ではないコードがどれほど多いかに驚かれるでしょう。パフォーマンスの最適化はボトルネックに対してのみ重要です。

個別の答えでは、事実上常にパフォーマンスが最優先されます。

このコードを 100 万回連続で実行するかどうかはわかりません。そのため、デフォルトではパフォーマンスが懸念されます。私たちの貴重なコードスニペットがアプリケーションのボトルネックになるかどうかは、それがどのように相互作用するかわからないため、わかりません。(ライブラリコードを作成するときにも同じことが起こります。これがどのように使われているのか分かりません。IMO コードを再利用する理由の 1 つは、単に「類似したコードを共有エンティティに移動する」ことではありません。)

保守性 コードが未知のコードとどのように相互作用するかによってさらに影響を受けます。答えは、設定した範囲内で問題を解決します。SQL、SQL Server、または MySQL を要求したり、それらとしてタグ付けしたりできます。残りの部分はわかりません。類似のコードパスはいくつありますか?プロジェクトの存続期間中、このコード部分はどのくらいの頻度で変更されるのでしょうか?特定のデータベースサーバーのバージョンを 10 年間使い続けるつもりですか? それとも頻繁に更新しますか?

保守性を解決するのは主にあなたの仕事です。あなたが尋ねた質問は、隔離すべき存在ですか?

可読性 ほとんど完了しました。残りはあなたの仕事です。回答するとき、私たちは通常、あなたが答えを理解することに関心があるため、少なくともあなたにとって読みやすいものである必要があります。そのスニペットをコードにコピーペーストして、 // That weird query それについてコメントしてください。もう私の問題ではありません。

これに加えて、パフォーマンスが理解しやすくなるという事実もあります。機能的に同等の 2 つの回答から、M+R 部門で大きな間違いがない限り、常に「ジョーの回答に似ていますが、少し速い」という回答を選択することになります。

今これを書いていると、時期尚早な最適化が誘惑されるのには理由があるように思えます。これはいくつかの理由により、優先順位が間違っています。

ただし、最適化の優先順位が低いのには、次の 2 つの主な理由があります。

正しさ 保守性、再利用性、パフォーマンスよりも重要です。正しさを目指すなら、残りの 3 つもお買い得に入手できるでしょう。

必要以上のコードは記述しないでください。
標準ライブラリを活用します。
賢さよりも透明性を優先します。
小さくてテスト可能な関数を作成します。

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

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

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

私は NASAでの作業を行います。しかし、私は本当のタイムコードまたはすべてがパフォーマンスが重要です任意のものを維持するか、または開発しない（現在はとにかく）です。 NASAで行わソフトウェアのほとんどは、おそらくではありません。私の一日でいくつかの恐ろしいコードを見た、私はまた、ほとんどのアプリケーションのパフォーマンス、その後、再利用が続く信頼性と保守性のジョナサンの答えと一緒に行きましょう。

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

「コンピュータ・プログラムは、人間が読んでincidentlyコンピュータによって実行されるように設計されています。」

私は私の仕事のこれらascpectsのすべてを評価します。しかし、私のコードの可読性（一部の用語の表現を使用）と私が一緒に仕事それらは重要なの私のリストを越えるます。

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

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow