タグ付けされた質問 「complexity」

複雑さは、コードの複雑さを計算するさまざまな形式を扱います。循環的複雑度、nパス複雑度、Big O時間および空間複雑度。

3
複雑さと到達可能性の間に相関関係はありますか?
最近、uniで循環的複雑度(McCabe)とソフトウェアの到達可能性を研究しています。今日、私の講師は、2つの測定値の間に相関関係はないと述べましたが、これは本当ですか? それほど複雑ではないプログラム(これまで見てきたわずかなものから)が到達可能性の点で「より良い」結果をもたらすように見えるので、間違いなく何らかの相関関係があると思います。 誰もが2つのメトリックを一緒に見ようとする試みを知っていますか?そうでない場合、多数のプログラムの複雑さと到達可能性の両方に関するデータを見つけるのに適した場所は何ですか?

15
オブジェクト指向プログラミングは複雑さの解決策ですか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 オブジェクト指向プログラミングは複雑さの解決策だと思いますか?どうして?このトピックは少し物議をかもすかもしれませんが、ここの専門家からなぜの答えを知るつもりです!

16
他のブロックはコードの複雑さを増しますか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 これは非常に単純化された例です。これは必ずしも言語固有の質問ではありません。関数を作成できる他の多くの方法、およびそれに加えられる変更を無視してください。。色はユニークなタイプです string CanLeaveWithoutUmbrella() { if(sky.Color.Equals(Color.Blue)) { return "Yes you can"; } else { return "No you can't"; } } 私が出会った多くの人々、ReSharper、およびこの男(コメントから、しばらくの間これを尋ねようとしていることを思い出した)は、コードをリファクタリングして、elseこれを残すブロックを削除することをお勧めします。 (私は大多数が言ったことを思い出せない、そうでなければ尋ねなかったかもしれない) string CanLeaveWithoutUmbrella() { if(sky.Color.Equals(Color.Blue)) { return "Yes you can"; } return "No you can't"; } 質問:elseブロックを含めないことで複雑さが増しますか? 私はelse、両方のブロックのコードが直接関係しているという事実を述べることにより、意図がより直接的に述べられているという印象を受けています。 さらに、特に後日コードを変更した後は、ロジックの微妙な間違いを防ぐことができます。 私の単純化された例のこのバリエーションを取り上げます(orこれは意図的に単純化された例であるため、演算子を無視します)。 bool CanLeaveWithoutUmbrella() { if(sky.Color != Color.Blue) { …

2
アルゴリズムの予想実行時間と平均実行時間はどういう意味ですか?
アルゴリズムの実行時間を分析したいとしましょう。入力サイズがnで、最悪の場合はO(n)で示される場合に、アルゴリズムの実行時間を見つけたいと言うことがあります。時々、アルゴリズムの予想時間を見つける必要があると言っている本/論文を見ます。また、平均実行時間が使用されることもあります。 「予想時間」とは何ですか?最悪の場合の時間ではなく、予想される時間を見つけることはどの場合に役立ちますか? 編集:予想実行時間と平均実行時間の間には微妙な違いがあると思いますが、よくわかりません。この投稿を通して、もしあれば正確な違いを知りたい。

6
Web開発の複雑さをどのように抑制しますか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 私はほとんどのキャリアでサーバーサイドのプログラマーでしたが、最近ではWeb開発により多くの時間を費やし始めました。適切なWebアプリケーションを作成するためにマスターする必要のあるものの数には驚かされます。習得する必要があるいくつかのツール/技術をリストするだけで、 サーバー側のプログラミング言語(Java / JSP、ASP、PHP、Rubyなど) 適切なWebフレームワーク(中規模から大規模のアプリケーション向け)。 HTMLとCSS Javascript Javascriptライブラリ(主にAJAX用のJQuery / ExtJSなど)。必要でない場合でも知っておくと良いでしょう。 少なくともWebデザインの基本的な知識-レイアウト、色、フォントなど Webセキュリティの十分な理解。 パフォーマンス/スケーラビリティの問題をよく理解している。 テスト、ブラウザの互換性の問題など。 リストは続きます。 それで、ベテランのウェブ開発者に対する私の質問は-どうやってたくさんのことを学び、自分自身を更新し続けるのですか?Webアプリケーションの開発中に、これらの分野に関係する複雑さをどのように処理し、適切に設計され、ユーザーフレンドリーで、安全で、パフォーマンスが高く、スケーラブルなアプリケーションを作成できますか。 ウェブ開発者として、すべての取引のジャックになる必要がありますか、それとも1つまたは2つの分野に特化し、残りをチームの他のメンバーに任せる必要がありますか?

4
一定時間と償却一定時間は実質的に同等と見なされますか?
一定時間(O(1))で追加とランダム削除を可能にするRandomQueueを書く必要があります。 私の最初の考えは、ある種の配列(ArrayListを選択しました)でそれをバックアップすることでした。配列はインデックスを介して常にアクセスできるためです。 しかし、ドキュメントを見ると、ArrayListsの追加はAmortized Constant Timeと見なされていることに気付きました。これは、追加には基になる配列(O(n))の再割り当てが必要になる可能性があるためです。 Amortized Constant TimeとConstant Timeは事実上同じですか、または追加ごとに完全な再割り当てを必要としない構造を調べる必要がありますか? 配列ベースの構造は別として(私が知っている限り、常に一定の時間での償却が追加されます)、要件を満たすものは考えられないため、これを求めています: ツリーベースのものはすべて、せいぜいO(log n)アクセスを持ちます。 リンクされたリストには、潜在的にO(1)が追加される可能性があります(テールへの参照が保持される場合)が、ランダムな削除はせいぜいO(n)でなければなりません。 完全な質問は次のとおりです。私がいくつかの重要な詳細にlazした場合に備えて: RandomQueueを設計および実装します。これはQueueインターフェースの実装であり、remove()操作は、現在キューにあるすべての要素の中からランダムに均一に選択された要素を削除します。(RandomQueueは、要素を追加したり、ランダムな要素に到達してやみくもに削除できるバッグと考えてください。)RandomQueueのadd(x)およびremove()操作は、操作ごとに一定の時間で実行する必要があります。

1
ドメインドリブンデザインは、それほど複雑ではないドメインに対して有用/生産的ですか?
作業中の潜在的なプロジェクトを評価するとき、ドメイン駆動型の設計アプローチをそのオブジェクトモデルに使用することが有利である可能性があることを提案しました。プロジェクトには過度に複雑なドメインがないため、同僚がこれを投げました。 DDDは、複雑なドメインモデルがある場合に有利であると言われています(「...複雑で複雑なドメインで運用している場合は常に適用されます」Eric Evans)。 私が失ったものは-ドメインの複雑さをどのように定義するのですか?ドメインモデルの集約ルートの数で定義できますか?オブジェクトの相互作用におけるドメインの複雑さはありますか? 私たちが評価しているドメインは、関連するオンライン出版とコンテンツ管理です。

8
複雑さをいつ除去すべきか?
設計パターンが必要になる前に実装することにより、時期尚早に複雑さを導入することは良い習慣ではありません。 しかし、すべての(またはほとんどの)SOLIDの原則に従い、共通の設計パターンを使用すると、機能と要件が追加または変更され、設計が必要に応じて保守可能かつ柔軟に維持されるため、多少の複雑さが生じます。 しかし、その複雑さが導入され、チャンピオンのように機能するようになったら、いつそれを削除しますか? 例。クライアント用に作成されたアプリケーションがあります。元々従業員に昇給を与えるいくつかの方法がある場所で作成されたとき。戦略パターンとファクトリーを使用して、プロセス全体をきれいに保ちました。時間が経つにつれて、アプリケーション所有者によって追加または削除される特定のraiseメソッド。 時間が経ち、新しい所有者が引き継ぎます。この新しい所有者は頑固で、すべてをシンプルに保ち、昇給する方法は1つしかありません。 戦略パターンに必要な複雑さはもはや必要ありません。現在の要件からこれをコーディングする場合、この余分な複雑さは導入しません(ただし、必要に応じてほとんど、またはまったく作業をせずに導入できることを確認してください)。 戦略の実装を今すぐ削除しますか?この新しい所有者が昇給の方法を変えることはないと思います。しかし、アプリケーション自体は、これが起こる可能性があることを実証しています。 もちろん、これは新しい所有者が引き継ぎ、多くのプロセスを簡素化したアプリケーションのほんの一例です。数十のクラス、インターフェース、ファクトリーを削除し、アプリケーション全体をよりシンプルにすることができました。現在の実装は正常に機能し、所有者はそれで満足していることに注意してください(そして、議論された複雑さのために、私は彼女の変更を非常に迅速に実装できたことに驚き、そしてさらに幸せです)。 この疑いのほんの一部は、新しい所有者が私をもう使用しない可能性が高いためです。大きな収入源ではないので、他の誰かがこれを引き継ぐことを本当に気にしません。 しかし、私は2つの(関連する)ことを気にします コードを理解しようとするとき、新しいメンテナーが少し難しく考える必要があることに少し気を配ります。複雑さは複雑さであり、私に続く心理マニアを怒らせたくありません。 しかし、競合他社がこの複雑さを認識し、仕事に時間を費やすためにデザインパターンを実装するだけだと考えていることをさらに心配しています。次に、この噂を広めて、他のビジネスを傷つけました。(私はこれが言及されたと聞いています。) そう... 一般に、以前は必要だった複雑さは、それが機能し、複雑さに対する歴史的に実証された必要性があったとしても削除されるべきですが、将来必要になるという兆候はありませんか? 上記の質問が一般的に「いいえ」と回答されたとしても、プロジェクトを競合他社(または見知らぬ人)に引き渡す場合、この「不要な」複雑さを取り除くことは賢明でしょうか?

3
クリス・ソーヤーがアセンブラーでジェットコースターの大部分を書くのにどのくらいの時間とどのような複雑さが関与していたでしょうか?
この質問から、別の質問があります... クリス・ソーヤーがアセンブラーでジェットコースターの大部分を書くのにどのくらいの時間とどのような複雑さが関係していたでしょうか? この質問を特定して分類するために、私は興味があります。 クリスが自分でゲームを書くのにかかったと推定されるおおよその工数(推測)または、アセンブラーのコーディング時間の比率のおよその割合を指定して、C / C ++ですべてを記述します。 アセンブラーをよく知っているプログラマーは、これをこのような低レベルの言語抽象化のための過度に複雑なタスクと考えていますか?パフォーマンス上のメリットは別として、これはChrisが持っている異常な自然の能力なのでしょうか、それともその程度の学習に値するスキルセットなのでしょうか?複雑さ/パフォーマンスのことはアセンブラーを習得する価値があると(書くために)考えているのか、それともアセンブラーで自然に発達したスキルをたくさん持っている場合(おそらくハードウェアの操作から) / hardware drivers / electronics / etc)。

8
複雑さのジャンプをどのように管理しますか?
時々プロジェクトに取り組んでいて、突然何かが突然現れて、作品に巨大なスパナを投げ込み、複雑さを大幅に高めることは、まれではあるが一般的な経験のようです。 たとえば、私は他のさまざまなマシンでSOAPサービスと通信するアプリケーションで作業していました。正常に動作するプロトタイプを作成し、その後、通常のフロントエンドを開発し、一般的に、すべてを素晴らしく、非常にシンプルで、簡単にフォローできる方法で実行しました。より広いネットワークでテストを開始し、接続の待ち時間とリモートマシンで計算を実行するのに必要な時間がSOAPサービスへのタイムアウトリクエストになったため、突然ページがタイムアウトするまで、うまくいきました。要求ごとに計算を実行するのではなく、バックグラウンドで段階的に更新できるように、要求を独自のスレッドにスピンアウトし、返されたデータをキャッシュするようにアーキテクチャを変更する必要があることが判明しました。 そのシナリオの詳細はあまり重要ではありません-実際、それは非常に予見可能であり、このタイプの環境用にこのタイプのアプリをたくさん書いた人々はそれを予想したかもしれないので、素晴らしい例ではありません-単純な前提とモデルから始め、突然プロジェクトの開発に複雑さをエスカレートさせることができます。 開発プロセスの後の段階で、またはテストの結果として、多くの場合仕様変更ではなく環境要因の結果として、これらのタイプの機能変更の必要性に対処するための戦略はありますか?可能性はあるが必ずしもそうではない可能性のある問題を軽減するソリューションを設計することで、同じくらい効果的である可能性が高いが、準備が整っていないソリューションを設計することで、時期尚早な最適化/ YAGNI /オーバーエンジニアリングのリスクを回避することのバランスをどのように取るか起こりうるあらゆる事態? 編集:Crazy Eddieの答えには、「あなたはそれを吸い込んで、新しい複雑さを実装するための最も安価な方法を見つける」ということが含まれています。それで、質問に暗示されている何かを考えさせられましたが、具体的には挙げませんでした。 そのバンプにヒットしたら、必要な変更を組み込みます。プロジェクトをできるだけスケジュールに近づけるが、保守性に影響を与える可能性があることを行いますか、またはアーキテクチャに戻って、保守性が高いかもしれないが開発中にすべてを元に戻すより詳細なレベルでやり直しますか?

5
扱いにくいドメイン固有のオブジェクトの名前付けのガイダンス?
私は化学システムをモデリングしていますが、列挙内の要素/アイテムの命名に問題があります。 私が使用すべきかどうかはわかりません: 原子式 化学名 省略された化学名。 たとえば、硫酸はH2SO4で、塩酸はHClです。 それら2つでは、合理的に一般的であるため、おそらくアトミック式を使用します。 しかし、Na2SiF6であるヘキサフルオロケイ酸ナトリウムのような他のものがあります。 その例では、原子式は(私には)それほど明白ではありませんが、化学名は恐ろしく長いです: myEnum.SodiumHexaFluoroSilicate。一貫した命名パターンを持つ短縮された化学名を安全に思い付くことができるかどうかはわかりません。 enum要素に名前を付けることで対処しようとしている問題がいくつかあります。 1つ目は読みやすさで、長い名前では問題が発生します。 2つ目は、新しいメンテナー向けのコードを簡単に選択できることです。ここでは、短い名前が問題を示しています。 次の問題は、事業主が通常完全な化学名を参照することですが、常にではありません。「一口」の化学物質は、その式で呼ばれます。 最後の懸念は、それが一貫していることを確認することです。どちらを使用するか覚えておくことができないので、私は混合命名規則を望んでいません。 メンテナンスの観点から、上記の命名オプションのどれをご覧になりますか?その理由は何ですか? 注:線の下にあるものはすべて補足です。明確化資料。動揺しないでください。主な質問は、厄介なオブジェクトの命名に関するものです。 アトミックオプション public myEnum.ChemTypes { H2SO4、 HCl、 Na2SiF6 } 化学名オプション public myEnum.ChemTypes { 硫酸、 塩酸、 ヘキサフルオロケイ酸ナトリウム } この質問に関するコメントからの追加の詳細を次に示します。 コードの対象者は、化学者ではなくプログラマーだけです。 私はC#を使用していますが、実装言語を無視する場合、この質問はより興味深いと思います。 私は10-20の化合物から始めており、最大で100の化合物を持っているので、可能なすべての化合物について心配する必要はありません。幸いなことに、これは固定ドメインです。 列挙型は、一般的/一般的な化学計算を容易にするためのルックアップのキーとして使用されます。つまり、式はすべての化合物で同じですが、化合物のプロパティを挿入して式を完成させます。 たとえば、化合物の質量(グラム)からモル数を計算する場合、モル質量(g / mol)が使用されます。FWIW、モル質量==モル重量。 一般的な計算の別の例は、理想気体の法則と特定気体定数の使用です。 サンプル関数は次のようになります。 public double GetMolesFromMass(double mass_grams、myEnum.ChemTypes chem) { double …

1
時間の相関と周波数空間の乗算の計算の複雑さ
画像処理技術(パターン認識など)の2次元相関を使用しています。時間空間での相関よりも周波数空間での乗算を使用するタイミングをどのように判断するかについて、理論的なアプローチがあるかどうか疑問に思っていました。2 x周波数空間のサイズの方が明らかに高速ですが、11などの小さく素数なサイズはどうでしょうか。

5
複雑なソフトウェアはどの程度の冗長性/堅牢性を実装する必要がありますか?
この質問の焦点:一部のソフトウェアは「余分な作業」を実行して、ソフトウェア内の1つまたは複数の内部エラーにもかかわらず「最終的に成功/満足」の結果を得る機会を増やします。結果が成功した場合、これらはすべてユーザーの知らないうちに発生します。 複雑なソフトウェアの定義: 存続期間中に10人以上の開発者によって作成(提供)されたコードが含まれており、同じ時間枠で記述されていない それぞれに注意事項がある10以上の外部ライブラリに依存 典型的なソフトウェアタスク(ユーザーが望む結果を生成するため)には10個以上の入力パラメーターが必要です。それらのほとんどはデフォルト値を持ちますが、ユーザーが制御を必要とする場合は構成可能です。 最も重要なことは、実行されるタスクに関連して適切な複雑さを持つソフトウェア、つまり不必要に複雑にならないソフトウェアです。 編集:複雑なものは何ですか?ComplexとComplicatedには大きな違いがあります。をご覧ください。(直接リンク) この質問内の冗長性/堅牢性の定義:(コメントに基づいて堅牢性を追加) 現在のパラメーターセットを使用したときにソフトウェアタスクが失敗した場合は、別のパラメーターを試してください。 明らかに、これらの「異なる」パラメータは異なるコードパスを使用し、結果として異なる(できればより良い)結果をもたらす可能性があるという内部知識が必要です。 これらの異なるコードパスは、外部ライブラリの観察に基づいて選択される場合があります。 最後に、実行される実際のタスクがユーザーの仕様とわずかに異なる場合、ユーザーは不一致の詳細を示すレポートを受け取ります。 最後に、10以上の構成可能なパラメーターと同様に、冗長性とレポートも構成可能です。 そのようなソフトウェアの例: データベース移行 ビジネスデータベース ソース管理データベースなど Word文書とOpenOffice文書、PowerPointおよびOpenOffice Drawなどの間のバッチ変換 ウェブサイト全体の自動翻訳 Doxygenなどのソフトウェアパッケージの自動分析。ただし、分析をより信頼性の高いものにする必要がある場合(つまり、単なるドキュメンテーションツールではない) パケットが失われる可能性があり、多くの再試行が予想されるネットワーク通信 この質問はもともと、意図的に悪いコードにどのように対処しますか?しかし、現在はソフトウェアの肥大化の原因の1つに焦点を当てています。この質問は、新機能の追加など、ソフトウェアの膨張のその他の原因には対応していません。 おそらく関連する: (巨大な)プロジェクトで複雑なコードを処理する方法 人々はどのようにして非常に複雑で読みにくいコードを書いて維持するのですか?

3
大規模なソフトウェアプロジェクトの実際の複雑さを測定する方法は?
大学のアルゴリズムコースでは、ハッシュテーブルやクイックソートなど、実際に使用されるさまざまな単純なアルゴリズムの複雑さを正確に計算する方法を学びます。 しかし、今では大規模なソフトウェアプロジェクトで、より高速にしたい場合は、個々のピースを見るだけです-いくつかのネストされたループは、より高速なハッシュテーブルに置き換えられます。より洗練された手法ですが、パイプライン全体の複雑さを計算することはありません。 それを行う方法はありますか?または、実際には、アプリケーション全体をグローバルに考慮するのではなく、アプリケーション全体を高速化するために、高速アルゴリズムを使用して「ローカル」に依存しているだけでしょうか? (私自身は非常に高速であることが知られている多数のアルゴリズムを積み重ねると、全体として高速なアプリケーションになってしまうことを示すのは自明ではないように思えます。) 他の誰かが書いた大規模なプロジェクトを高速化することを任されているため、私はこれを求めていますアプリケーション全体。

5
アルゴリズムのランダウ表記(Big OまたはTheta表記)をプログラムで見つけるには?
私は、アルゴリズムを可能な限り最適化するために、手作業でアルゴリズムのLandau(Big O、Theta ...)表記を検索するのに慣れていますが、関数が本当に大きく複雑になっているとき、それはうまくいきません手でやるには時間がかかりすぎます。また、ヒューマンエラーが発生しやすくなります。 私はCodi​​lity(コーディング/アルゴリズム演習)に時間を費やし、提出されたソリューションのLandau表記(TimeとMemoryの両方の使用量)が表示されることに気付きました。 私は彼らがそれをどのように行うのだろうと思っていました...どのようにあなたはそれをしますか? 字句解析またはコードの解析以外の方法はありますか? この質問は主にPHPやJavaScriptに関係していますが、私はどんな言語や理論にも心を開いています。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.